On Wed, Mar 29, 2000 at 09:53:54AM +1000, Craig Sanders wrote: > > the only thing that is likely to speed up the release cycle is the > rolling release part of the package-pools idea....which, if you examine > how it is supposed to work, actually works by making unstable MORE > stable, not less - packages only get promoted from incoming/"holding" > to unstable when they pass certain tests (e.g. lintian test, all > dependancies met, no bug reports for XX days)...and they only get > promoted from unstable to frozen when they pass more tests. in other > words, it automates as much of the job as is possible. This started me thinking. Someone earlier lamented the difficulties in using experimental. I would like to see experimental moved into the same tree as stable, frozen, unstable and have a Packages file generated. New packages (and perhaps all new upstream releases) would be autoinstalled into experimental until they had been there for a month (or someone could get to the overrides file for unstable, whichever is longer), and packages with Grave or worse bugs open longer than a week (or maybe 2 weeks) would be moved there. This would allow lintian checks to become a prerequisite for unstable, especially now that developers can write their own overrides for special cases. People inclined to live dangerously can then test experimental by simply adding it to the apt sources. Is this feasable from a technical standpoint? > personally, i'm not going to hold my breath waiting for the stable > release cycle to speed up. it's a big job, and one that grows enormously > for every release. we had around 2000 packages for slink. we now have > approx 4000 for potato....and already nearly 5000 for woody - and potato > isn't even out the door! One of the things that might help this would be continuous freeze. As soon as a release is made, whatever is in unstable at that moment is frozen for the next release. This will become more feasable as package graduation becomes more refined, I think. > i'm glad i don't have to wait. unstable is more than good enough for > use on production servers (and has been the entire time i've been using > debian - almost 5 years now) I've been around for less than half that, but I do remember a nasty bash/libreadline bug that flattened a number of systems that I would not have wanted to encounter on a production system, as well as a few X problems. Furthermore, I would not want to deal with an application server running unstable. While I admit that the quality of Debian packages is generally quite high even in unstable, I would remain rather wary of recommending it for production servers. -- Zed Pobre <firstname.lastname@example.org> a.k.a. Zed Pobre <email@example.com> PGP key and fingerprint available on finger; encrypted mail welcomed.
Description: PGP signature