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 <aj@humbug.org.au> <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
Attachment:
pgp56bcwAro7f.pgp
Description: PGP signature