On Thu, Aug 17, 2000 at 10:17:30PM +1000, Anthony Towns wrote: > Hello world, > So, on -devel-announce, I mentioned: > > * New "testing" distribution > [...]
So some more details. The way testing is supposed to work is to have three distributions at any one time: a stable tree, a testing tree, and an unstable tree. As we make releases and such, this'll look roughly like: stable testing unstable ~~~~~~ ~~~~~~~ ~~~~~~~~ potato woody sid (when testing's rolled out) woody [foo] sid (when woody's released) [foo] [bar] sid [bar] [baz] sid So basically we're splitting "the development tree" and "the release candidate" a little. Not really very *much*, the release candidate's still heavily based on the development tree, so they're by no means independent, but hopefully the separation will be useful. This probably changes the way we deal with unreleased architectures a bit too. Architectures like sparc64, mips, mipsel, hurd-i386 and the forthcoming superh are all in development, but aren't release candidates yet. As such, it will presumably be appropriate to leave them in unstable, without linking to them from testing, at least until they're ready for release. This is fairly similar to the current motivation behind sid; hence the reuse of that existing distribution rather than creating a completely different one. As far as maintainers go, they more or less just need to keep uploading to unstable. They still need to be careful to only upload things that are more or less ready for release, it's not really reasonable to have two different forks of a package in the different distributions (as it is for stable/unstable or even for frozen/unstable). Basically, the version is testing simply won't get updated until the problems with the version in unstable are worked out. If a maintainer wants to be a bit more careful about gettig their software ready for release, they can look at reports like that at http://auric.debian.org/~ajt/update_excuses.html to see if testing's noticed any problems. (At the moment, these aren't mailed to maintainers or anything? Should they be? They're all (supposedly) worthy of an RC bug, so in many cases the maintainer will already have been notified because a bug will have been filed) If a maintainer specifically *doesn't* think a package should be considered a release candidate just yet, then all s/he has to do is file an important bug against the package, and it'll be held in unstable while that bug's opened. Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``We reject: kings, presidents, and voting. We believe in: rough consensus and working code.'' -- Dave Clark
pgp6oGKzOhEV6.pgp
Description: PGP signature