Re: potato late, goals for woody (IMHO)
Mike Bilow <mikebw@colossus.bilow.com> writes:
> Again, the idea behind a six-month cycle is to do three months of
> upgrading and three months of testing.
This sounds like a plan. The freeze-in-3-months deadline is a
realistic goal. If the freeze will be done in 3 months, is a different
question.
If we can hold up this scheme, packages in stable will be 3-6 months
old, which is a quite acceptable price for well-tested software.
> Where I think my comments have been giving the wrong impression is that I
> am by no means advocating a rigid schedule. If, for example, we know that
> there will be a major upgrade of something like glibc released in 10/2000,
> then it makes sense to postpone the freeze from 9/2000 to 10/2000, and
> then to get the new glibc tested for release targeting 1/2001.
I don't think that is reasonable. A major new libc version means a lot
of incompatibilties in a lot of packages. Putting it in right before a
freeze will probably make testing harder and longer. Furthermore, none
of the projects we're talking about commits itself to a release date.
Would you have postponed the potato freeze because 2.3.99-something
was out? 2.4.0 is still not here ...
Remember that under a 6-month-cycle the kernel, for example, will be
at worst at the level it was 6 months ago. 2.2.13 is two weeks older
than that. 2.2.8 is celebrates its first birthday in a few days!
> On the other hand, if we miss the new glibc and it comes out in,
> say, 11/2000 and we decide not to wait, then we should be able to
> get it into the next release targeted for 6/2001. Is this making
> more sense?
Yeah, though I think we should not usually wait for stuff. Sometimes,
the train has to leave the station.
--
Robbe
Reply to: