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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100922130147.gh4...@rivendell.home.ouaza.com
