Re: Debian's problems
On Tue, Sep 14, 1999 at 08:23:53AM +1000, Craig Sanders wrote:
> 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
>
>
> --
> craig sanders
Agree with you. I just want to add that we should let the maintainer
retain is package from being "forked" by, for example, filling a
special bug against it in the BTS. Package with this special bug will
never go into the release candidate.
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
------------------------------------------------------------------------
Fabien Ninoles Chevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail: fab@tzone.org
WebPage: http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
------------------------------------------------------------------------
Reply to: