Re: potato late, goals for woody (IMHO)
On 2000-05-06 at 11:20 -0500, Steve Greenland wrote:
> > example, if you have a reasonable expectation that there will be a major
> > kernel upgrade along the lines of 2.2.x to 2.4.x, then it would be foolish
> > to ignore this if delaying a month would let you get the new kernel in and
> > tested.
>
> Speaking specifically of kernels, if we did get to the point of
> releasing every 6 months, then waiting for kernel 2.4.0 would be a bad
> idea. Instead, we should pick up 2.4.7 in 6 months. Otherwise we get
> criticized for including a broken kernel in our supposedly stable dist.
> Similar reasoning applies to other major packages..
Again, the idea behind a six-month cycle is to do three months of
upgrading and three months of testing. As an example, let's assume that
potato comes out in 6/2000, so that means we would integrate new packages
into woody until 9/2000 (including all of those which have been split
since the beginning of the potato freeze and are newer or present only in
woody), and then do bug-fixing until about 12/2000. If something like a
kernel upgrade was not available by 9/2000, then it would not go in unless
it was an extremely important issue, where importance was evaluated using
essentially the same standards as apply now during a freeze. The goal is
to make sure that anything which gets into the 12/2000 relase is (a) fully
tested and reliable, since there would have been three months of testing
under freeze, and (b) no older than three months.
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. 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?
The problem I am trying to solve is that we need to avoid a situation like
we have now with slink. The current canonical slink release (2.1r5, with
boot-floppies 2.1.12-1999-12-09) installs kernel 2.0.38 and glibc 2.0, and
has packages such as gcc 2.7.2.3, PCMCIA CS 3.0.5, Apache 1.3.3,
PosrgreSQL 6.3.2, PHP 3.0.5, and so on. Kernel 2.2.0 was released in
1/1999, several months before slink! No widely used distribution is still
based on pieces this old, and many prrogams cannot even be built from
source with a non-egcs compiler and glibc 2.0. This situation has
developed because we are now guaranteed a minimum of 14 months between the
release of slink and the release of potato -- this is just way too long.
> > Debian was managing a six-month release cycle some years ago.
>
> When we had far fewer developers and 1/5th as many packages.
I don't have any magic solutions. My reasoning process is that any
release cycle much longer than six months starts to have serious
detrimental effects on users, because that cannot run -- or even build --
what they need to suit their purposes. So then the question is: how do we
achieve a six month release cycle? I feel that a three-month period of
integrating alternated with a three-month period of testing is one way.
If that really cannot be accomplished, then perhaps Debian needs to be
split up into smaller tasks which release at different times. For
example, there could be a more relaxed policy about adding things to a
released stable tree, and "important" things could be upgraded. The
problem with this is that nearly anything important is by definition
pervasive, like the kernel or glibc, so upgrading it separately is
actually more likely to break the distribution rather than less.
-- Mike
Reply to: