On Sun, Oct 24, 1999 at 07:32:40PM -0200, Lalo Martins wrote:
> PROPOSAL: NEW (`Incremental') RELEASE PROCESS --- DRAFT
Here's my preferred alternative. I don't want to advocate it too strongly,
since it doesn't have working code yet. Consider it advocacy for `further
discussion' if this proposal gets the requisite number of seconds.
Basically, what I'm thinking would work would be three distributions:
stable, testing, unstable (note the sorting order! I'm so proud.)
Stable and unstable would remain more or less exactly as they are now. There
aren't any changes to dinstall, or how/where you upload to, etc.
Testing is a distribution that's completely automatic --- a program
(with minimal human assistance, I'm not entirely clear on how to manage
this) selects packages from unstable that satisfy a number of criteria
and replaces the existing versions in testing with versions from unstable.
The criteria I think would be best are:
* binaries for all appropriate architectures have been built
* they are installable using just packages from testing
* they don't make any other package in testing uninstallable
* the package doesn't have any outstanding release-critical bugs
* this version of the package has been in unstable for a fortnight
or more
This has a number of nice properties:
* no extra work if you don't really care about the release cycle.
If your packages are bug free, they get released, if they're not,
they don't.
* we have a `fairly up to date, and not too broken' distribution
to point people at, rather than `way old, but not broken' and
`up to the second, but flakey'.
* presumably this means `testing' gets a much wider audience than
unstable. as such, the only way to really get a package out
to `tha people' is to fix your RC bugs, which theoretically
encourages people to do so promptly, rather than just around
freeze.
* if you want to upload something to unstable, but don't want it
released, this is as simple as filing a bug report like:
Subject: foo isn't suitable for release
Package: foo
Version: 1.1
Severity: important
and the script will ignore the package.
* people are given a reasonable length of time to find any horrible
bugs in a package before the last working copy of the package
is removed from the archive forever.
There are a couple of major drawbacks, at the moment.
One, is that the code to do all this isn't written. (Actually some of it
is, and I'm hoping to start testing it around the time potato's released,
but no promises)
The other is that it implies doubling the bandwidth required to mirror
Debian, once to mirror `unstable/foo' then a fortnight later, to mirror
`testing/foo'. A package pool is one way of solving this, but it makes it
difficult to mirror a single architecture.
Hmmmm.
http://www.debian.org/~ajt/testing-19991025.tar.gz for what code I've
done, fwiw.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP 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
Attachment:
pgpdrvNBQMDc3.pgp
Description: PGP signature