[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: incremental release process (the package pool)

On Sun, Oct 24, 1999 at 07:32:40PM -0200, Lalo Martins wrote:

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

	* 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.


http://www.debian.org/~ajt/testing-19991025.tar.gz for what code I've
done, fwiw.


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: pgp5pGB3muGT0.pgp
Description: PGP signature

Reply to: