Re: Release management - technical
In article <[🔎] E0yjQDk-0003WO-00@chiark.greenend.org.uk> you wrote:
: 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'.
Yes.
I find it impossible to completely divorce the conceptual model from any
reference to details of the present or any proposed implementation, but I'll
give it a try.
One of the difficulties we have right now is that, whether we admit it or not,
we have a three-phase distribution mechanism. The first is "pre-unstable"
which is currently made up of the Incoming directory, and files that get
parked on a number of sites around the world because some users want these
packages, and the delay through Incoming for a new package is large. The
second is 'unstable', which as many have pointed out is often not very
unstable at all... but it can get that way from time to time. The third is
the 'stable' tree, which has value for folks who want to press CD's, but is
not of much interest to anyone I've met who is net-connected.
The problem with 'frozen' is that it's a release candidate whose rules for
formation and maintenance are such that for a time, at least, it was far less
stable than 'unstable'! It is also unfortunate, but predictable, that with
our current process for freezing and releasing from 'unstable' that we end
up with this release-candidate sitting around for many months... which is
insane.
In one of the proposals that is floating around, that incorporates some ideas
I posted earlier along these lines, this three-phase nature of what we do
becomes more explicit. The 'unstable' tree becomes just what it says it is.
Any new package from a registered developer moves instantly from Incoming to
unstable. What we have called 'unstable' in the past gets a new name, like
'unreleased' or 'pre-release' and in effect is a continuously-available
release candidate that all developers would be expected to be running and which
therefore would get lots of ad-hoc testing.
Incoming -> unstable -> unreleased -> stable
The "Incoming -> unstable" transition is instant. The "unstable -> unreleased"
transition applies all the structural rules for a stable release (dependencies,
lintian rules checks, etc), and requires that the version in unstable have
been present without new bug reports for some period of time. The
"unreleased -> stable" transition is performed by the release engineer when
the unreleased tree is in a good state and the clock ticks the appropriate
hour.
Thus, the release process from 'unreleased' to 'stable' would be a much less
momentus event... and would, for the most part, be the act of freezing a
snapshot of the current release candidate, perhaps tweaking the one or two
items like installation media which tend to get last-minute attention before
a stable release. Everybody wins! Those who want/need bleeding edge stuff
don't have to look so hard for it. Those who want a stable release that
doesn't break structural expectations get that. The testing job gets easier
because more people are helping. The release manager has an easier job because
there's always a release candidate around in good condition.
I'm already on record as being willing to help code some of the process
changes that a scheme like this would require... but I think we ought to get
hamm out the door, first... and soon.
Bdale
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: