Re: potato late, goals for woody (IMHO)
I was going to suggest something similar, and found a minor drawback:
you're going to effectively need two sets of maintainers and a handoff
mechanism. One set of unstable maintainers that ensure that unstable
stays on the bleeding edge, and one set that does nothing but bugfixes for
the frozen->stable xsition. The reason that this is a minor problem and
not the show stopper it seems is that there's an elegant solution
slapping us in the face ATM: new-maintainers. Set up some kind of
apprenticeship program that a new maintainer must do N releases of
bugfixes before they can go into unstable mode and do ITPs (or N releases
of packaging only before they're let loose on the RC bugs...either way, it
makes little difference to the elegance of the solution). The handoff
mechanism might just be an extension of the mentorship/sponsorship
program.
On Wed, 3 May 2000, Mike Bilow wrote:
> Not having to touch a system is a win. Not being able to touch a system
> without it being called "unstable" is a loss.
>
> I am going to have my head handed to me for suggesting this, but why not
> move to a three-tier model on a semi-permanent basis, much like we have
> during a period when frozen exists? That is, shortly after the release of
> potato as stable, then we freeze woody and create a new unstable tree
> called zurg or whatever? That would effectively guarantee a shorter
> release cycle with little decrease in technical quality. If we did it
> this way, there would also be less pressure and scrambling to make sure
> something gets into the freeze of any particular version.
>
> We are already in a serious problem because, at best, potato will likely
> be followed shortly after its release by the 2.4.0 kernel and, at worst,
> will be released on the 2.2.x kernel after the 2.4.0 kernel has been
> released. It would make logical sense, after potato is finally released,
> to focus on getting woody out the door as soon as possible on a 2.4.x
> kernel. That's a pretty realistic goal, and it would pretty much involve
> declaring woody frozen whenever the 2.4.x kernel series settles down. It
> may be possible to handle 2.4.x kernel support by simply backing it into a
> subrelease of potato, much as we did with slink and the 2.2.x kernel, but
> what's the point? In my opinion, it is possible and desirable to target
> woody for release about six months after potato is released.
>
> A shorter release cycle would mean that there is less change between
> consecutive versions, barring major upheavals on the order of converting
> from a.out to ELF, which should mean less to break and less to fix. I
> could easily see doing woody with about six weeks of freeze and six weeks
> of testing cycles, or maybe eight weeks of freeze and four weeks of
> testing cycles. Simply announcing a planned freeze as a rough goal as
> long as two or three months in advance could itself go a long way to
> speeding things up substantially and achieving a six-month cycle.
>
> I would have to check this, but my recollection is that Red Hat and SuSE
> have each done two numbered releases since potato has been frozen. The
> Debian release cycle is trying the patience of the user community.
>
> >From the perspective of users, Debian is what gets out the door.
>
> -- Mike
>
>
> On 2000-05-03 at 21:18 +1000, Anthony Towns wrote:
>
> > Because of late we seem to be taking four or more months to do a freeze.
> > That leaves us, as a distribution, completely dead in the water: stable's
> > not being updated any more than it ever is, frozen's not getting any
> > new packages, and unstable's being ignored so that frozen can be fixed
> > up for release.
> >
> > And because being able to just leave a system running and not have to
> > touch it for a year except to run apt-get to keep it up to date with
> > security patches is, IMHO, a win.
>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
FINE, I take it back: UNfuck you!
Who is John Galt? galt@inconnu.isu.edu, that's who!
Reply to: