Re: potato late, goals for woody (IMHO)
I thought of that when I was writing this, but it also seems to me that
the shorter release cycles could solve that problem. If we target a
six-month release cycle, you just alternate between three months of
working on unstable (or whatever it is called) and three months of
bug-fixing on frozen. This means that, by release as stable, no package
should be more than three months out of date. In summary, I think it
would be LESS work to have shorter release cycles because the increment
would be smaller between what we know works and what we must test.
The key, I think, is to let everyone know well in advance what to expect.
"It's ready when it's ready" is not working. I would suggest that freezes
should be loosely tied to anticipated events of pervasive significance,
such as the change of the kernel from 2.2.x to 2.4.x., an upgrade of glibc
version, or something of that sort, possibly to a major release of a
high-demand application such as Apache. Applications will be less of an
issue because, if there are smaller gaps between releases, there is a
greater likelihood of success in running one or two specific packages from
the unstable tree on an otherwise stable installation, for those who
choose to go that route.
If we say now that we are going to target a freeze of woody about three
months after the release of potato, and then a release of woody three more
months after the freeze, then everyone can plan accordingly. This would
not compromise quality by reducing testing, but rather would promote
quality by thoroughly testing smaller increments more often. And, as I
said, I think it would reduce the work involved in such horrendous efforts
as we are experiencing with a November-to-May (-June?) freeze.
At one time a few years ago, Debian was on a six-month release cycle.
-- Mike
On 2000-05-04 at 14:09 -0600, John Galt wrote:
> 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.
Reply to: