I think that in order to make sense of what's being said here we need to step back a bit, and think about abstractions rather than implementation. Lots of people (myself included) have been posting rather detailed proposals.
Q. What are we trying to achieve ? A. There are two possibilities that I can see - Timely and good-quality releases, or - Releases which meet some predefined set of goals. I think we can only do one of these. With hamm we're doing the latter; in the future I think we should do the former. Most people seem to be in agreement that the release management process needs to decouple things, and we've been talking a lot about a `foo distribution' for various values of `foo' (`unstable', `frozen', etc.), where a distribution is a collection of various versions of various packages. We need to think about what kinds of thing need to happen to a package or to a distribution before we release it as `stable'. As a starting list, things that have to be OK for a package to be called `stable': * maintainer can do build and initial testing * package has been tested (formally or informally) for some time and no (sufficiently serious) problems have been found For a whole distribution, I think we have: * all packages' dependencies can be satisfied * other mechanical consistency checks (file overlaps, priority/dependency checks, etc.) are OK * distribution or something very like it has been tested and no sufficiently serious problems have been found I think `or something very like it' is very important here. We have a strong ability in our packaging system and general architecture to upgrade individual pieces in case they need fixes. We should be able to do this if we think it's likely to be a good idea. Now, many of the proposals that I've seen so far allow a large version skew between released stable and development versions. I think this is generally a bad idea, because * old versions are harder to maintain for all sorts of reasons * our developers are often not interested in maintaining old versions * developers are using a different system to the users, so we don't get so much testing by developers So, I think we should be prepared to back off broken things even in our working unstable tree, if they look like they aren't being fixed. The stability criteria I described above seem to suggest that _time_ itself (if no bugs turn up) can turn a package from being considered unstable to being stable. There seems to be some argument about whether unstable packages should be `aged' into stable. I'm strongly of the opinion that they should. Note that I'm not proposing a scheme in this message. Rather, I'd like people to read these comments and think about and respond to the issues involved. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]