Re: unstable/testing/[pending/frozen/]stable
Hi all,
On Tue, 21 Sep 2010, Yaroslav Halchenko wrote:
> CUT discussions at debconf10 and recent news of the birth of Linux Mint
discussions on CUT have continued after debconf on the CUT mailing. I
wrote a summary of the discussion that will be published in Linux Weekly
News before tomorrow.
Hopefully this summary will then lead to a constructive discussion on the
way forward.
http://cut.debian.net/
http://lists.alioth.debian.org/pipermail/cut-team/
> [experimental/]unstable(sid)/testing(e.g squeeze)/stable
>
> *constantly* present and functioning all the time the same way.
You're not alone wishing that. I also would like Debian to provide a
rolling distribution that never stops to roll. :-)
> NB I am having some deja vu that 'frozen' used to be used explicitly
> in the archive... is that so?
Yes. frozen was a snapshot of unstable at time of freeze, and people could
upload to frozen directly afterwards to fix remaining RC bugs.
> But I cannot be first thinking about that, and I bet there were good
> reasons why such approach was not taken -- could anyone enlighten/point
> me to the shortcomings?
I'm not sure it was an explicit choice at that time. We just had to adjust
the way we dealt with freeze once testing was introduced. Getting fixes
from unstable is easier/safer for everybody compared to
testing-proposed-updates so release managers asked people to not upload
packages which could not migrate to testing and many do. It also means
unstable is less interesting during freeze. Also having the package in
unstable for some time ensures that it doesn't break horribly, something
that you don't have with testing-proposed-updates.
There is room for improvements here I think.
On Wed, 22 Sep 2010, Mehdi Dogguy wrote:
> It means that the Release Team will have to handle transitions in
> unstable, migrations to testing, as well as the ongoing freeze in
> "frozen". I don't think we have enough manpower for that. And, during a
> freeze, we need each one to concentrate on fixing things (while there is
> still experimental to test things). If we add a play-forever-suite, we
> will loose some manpower without any doubt and it will make releases
> harder to acheive, imho.
I think that if you concentrate on preparing the next release like you do,
volunteers that are not interested in the stable release (except for their
own package) will show up and deal with migrations to rolling.
It's always the same story, you can't force people to care about stable
simply by not having a "play-forever-suite". And we do have people working
on derivative distributions that rely on testing's constant freshness,
maybe some of them would be interested to help as well.
Anyway, I'd like to ask you all to hold off the discussion for a few hours
until everybody can read the summary of the CUT discussions and have a
clearer ideas of the proposals and the implications.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: