Re: 2.4.0!

[Mike Bilow <mikebw@colossus.bilow.com>]

On 2000-05-25 at 23:00 -0700, Joseph Carter wrote:

> Not to put too fine a point on this, but just HOW THE HELL do you propose
> to shorten release cycles?  I've watched Hamm, Slink, and now Potato go
> through the same things.  Everyone wants to shorten release cycles, but
> every attempt made to do so is totally ineffective.

I think the absolute first step is to announce some kind of long term
plan.  It is, I think, the absence of any kind of announced schedule that
could keep everyone on the same course which is the principal contributor
to time slip.  "It's ready when it's ready" leaves everyone completely
unable to plan effectively, since no one knows whether they have a week, a
month, or a year to accomplish their goals.

If it was generally understood three full months in advance that the
intention was to freeze on a particular date, then at least maintainers
would have some ability to plan what they could get done by that date and
how much to take on.  The announced date could be allowed to slip a bit if
necessary, but there should be a good reason.

> When I met last summer with several Debianites over dinner (among them
> joeyh, wichert, gecko, and others), it was generally agreed by all of us
> that the only way to shorten release cycles was to either start making
> incremental releases or to move toward a unstable being a pool which
> packages deemed stable enough to release are picked from and tested in a
> nearly constant release preperation modality.

If you got enough Debianites together over dinner, it would take three
days just to settle the check.

> If you think about it, both of these schemes boil down to the same
> prospect:  Adding packages as they become stable to an already stable
> distribution.

I would support trying anything: package pools, shorter release cycles,
whatever there is a consensus behind.  I think shorter release cycles
would be easier to try, frankly, than package pools.  Part of my concern
is that it is far from obvious what would constitute pools defined by
"everything that uses gnome" or "everything that uses X" or "everything
that uses libc6."  Eventually, you get back to where we are now.

> Three months of aggressive development in unstable is going to require a
> six month freeze at the bare minimum.  It's happened before, several
> times.  The larger Debian gets, the more true this will be and the longer
> the release cycle is going to take.  What makes you think the next release
> will be different?  dark thought Potato would be different.  Was it?  Not
> really.

I simply don't see this.  It seems to me that the length and complexity of
the freeze is primarily related to the amount of distance which is allowed
to develop between successive stable releases.  Shorter release cycles
would minimize the distance between successive stable releases.  The
Potato freeze has lasted longer than would be ideal, so there would be
some pain in the distance between Potato and Woody, but it will still be
much less than the distance between Slink and Potato.

> You seem to think that this extensive testing of major system component
> upgrades can happen in equal time after agressive development which
> history has shown breaks things, ESPECIALLY when done on the scale of
> Debian.  Do your homework.  What you propose has been tried time and
> again with failure each time.  Come up with something that has a chance,
> I'm tired of rehashing what experience shows does not and cannot work time
> and again.

Look, I don't think the fundamental problem with the release cycles is
technical; rather, I think it is that no one is told the plan.  If people
are given a general idea of what to expect over the course of about six
months, then they can deal with this.  The schedule does not have to be
adhered to as a matter of rigid obeisance, but it does have to have some
sort of general acceptance as significant.

I will go so far as to say that the actual plan is less important than the
simple fact that there be a plan and that everyone knows what it is.  I am
not trying to argue in terms of broad generalities for a shorter release
cycle, but to suggest a particular and specific course of action that I
think makes a fair amount of sense and has a good likelihood of success.

-- Mike