On Thu, Mar 30, 2000 at 01:30:58PM -0600, Zed Pobre wrote: > 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.
experimental already has a Packages file generated, and where it is in the tree is more or less irrelevant. > New packages (and perhaps all new upstream > releases) would be autoinstalled into experimental until they had been > there for a month This gets rid of the main use of experimental which is to distinguish packages that'll probably destroy your system, against ones that shouldn't but might because, well, anything's *possible*. > (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. A different way of doing it is to leave unstable as it is (ie, new packages get lumped into unstable whether they work or not, assuming they're not /likely/ to trash your system), and instead add a new distribution inbetween stable and unstable, that has some of the properties of stable (ie, packages have more or less stabilised, they've been tested for a while, they've got few/no RC bugs, they work on all architectures, packages don't have huge dependency problems). Particularly the latter of these is a fairly complicated technical problem to solve. Exercise to the interested reader: try it at home. Implement your solution. Time it. Try to optimise it. (20pts) For the less interested reader, point your browser at http://auric.debian.org/~ajt/. For the reader who doesn't give a stuff and just wants to cut to the chase, point apt at, hopefully, deb http://auric.debian.org/~ajt/ testing main . It's still very alpha, and relies heavily on the autobuilders being up to date against woody, which isn't the case while we're frozen. As such, please be wary of mirroring this: when we think it's really worth the effort of mirroring it'll probably go into /pub/debian/dists, and until then, it's quite probably a waste of bandwidth. Source is theoretically available, but only by ssh'ing to auric and poking around in my home directory. > This > would allow lintian checks to become a prerequisite for unstable, > especially now that developers can write their own overrides for > special cases. Someone would need to go through all the lintian checks and see which ones are actually worth making RC. Not all of them are by a long shot. > > 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. Note that I at least, refuse to fork my packages during the freeze. It's just too painful to work with. > 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. There was a cute grep bug a while ago too, that made grep simply not work if you specified the files to grep on the command line (or the other way around, I forget). There are lots of cute bugs around in unstable now and then, but they're generally easy to recover from if you have a clue. If you don't want to have to have a clue for production servers (and I for one don't), well, that's what stable's for. Possibly, it'll also be what `testing' will be for, up to a point, when and if it actually works. BTW, I've been thinking recently. The original point of `testing' was to make it easier for us to release (you've got a whole semi-unstable distribution that's up-to-date and more or less bugfree from the word go. No more bug horizons, just a few finishing touches, some organised testing on the final product, and voila!), and hence make it easier for us to release more often. I wonder, though, if that's really a good idea. At some point, frequent releases are just a downright pain, even with Debian's fetish towards in-place and partial upgradability. Maybe it'd be better to just keep releasing once-a-year or so (with any extra security-fixes), and let people who really want new packages upgrade to testing. As opposed to making a release every three, four or six months, say. And, of course, none of this solves our current problem, which is that there's just too many *new* RC bugs. 140 new, previously unreported, RC bugs in the last fortnight or so. Scary. Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds
pgpC9sLh8Mo9p.pgp
Description: PGP signature