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

Re: Debian's problems

On Mon, Sep 13, 1999 at 06:25:33PM +1000, Anthony Towns wrote:
> [0] viz, a kind of semi-unstable that only gets packages added to it
>     if they're immediately releasable. ie, they don't break boot-floppies,
>     don't break CD-rom building, and don't have any release critical
>     bugs. See somewhere under http://www.debian.org/~ajt/ for some
>     ideas/discussion/proposal on how this might be made to work.

yes, we should have done this long ago - i thought it was a brilliant
solution to the (ever recurring) debian release problem from the first
time i read bdale's "package pool" proposal, and his analysis of the 3
main types of debian users.

looking at your page, it looks like that was sometime in May 98. approx
18 months ago just before we released hamm, i believe. it got re-hashed
several months later, just before the release of slink....i thought we
achieved consensus THEN that we were going to implement bdale's idea (or
something very like it).

now, just as we're talking about the release of potato we are going over
the idea again. i think this pattern is highly instructive. we need to
do more than just talk about it near the end of every release cycle.

talking about it is good, but at some point we have to bite the bullet
and actually do it. most people agree that something has to be done.
many agree that the rolling-release or package-pool idea is the Right
Thing - the idea has been re-invented several times. it appears to be
the only practical way of releasing more than once or maybe twice a
year. lets do it.

btw, my preferred variant of the package-pool idea is that the release
manager has the right to fork a snapshot at any time and call that the
"release candidate". the RM and other release-team volunteers have
complete control over that candidate, doing *whatever* they feel is
necessary to turn it into a releasable product, including the right
to make any NMUs they need if the real maintainer is unable to work
to their schedule. i call it a "fork" because development in unstable
continues as normal, but the release team must have complete control
over the release candidate.


craig sanders

Reply to: