Release management - technical
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 debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: