Re: 2.4.0!

[Joseph Carter <knghtbrd@debian.org>]

On Fri, May 26, 2000 at 02:34:27AM -0400, Mike Bilow 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.

Even when freeze dates are announced a month in advance, there are tons of
last minute uploads a week or even a day before freeze.  This usually
includes something that totally screws the newly frozen tree (a new
compiler, a new X, something..)


> 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.

I really believe an announced date will just cause people to put off for
tomorrow what they should have done last week.


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

There were about 6 or 7 of us, details do fuzz a bit after just shy of 10
months.


> > 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.

My concept of a package pool was pretty simple..  A stable release just as
we have now, a release-candidate much like frozen is now, and an unstable
pool.  As packages (rather than distributions) become stable, they're
marked for addition to the release-candidate tree.  when their
dependencies are satisfied (which is the issue - dinstall currently cannot
do this and so doing is not a trivial modification), the package can be
moved into the pre-release group.

At any time and with minimal freezing for test cycles and installation/CD
images as we're doing right now, the pre-release tree should be able to be
released.

This allows for the three kinds of users Debian has:
 1. those who want a stable distribution (stable)
 2. those wanting new software, able to handle minor fuckups  (pre-release)
 3. those on the bleeding edge (unstable pool)


Extension of this scheme would be to allow tools such as apt to have
distribution lists from which it installs new packages automatically and
from which it does not (but could without reconfiguration..)  I could set
up apt to install stable and pre-release packages automatically but make
unstable available to me without automatically upgrading.

If foo has 1.0-2 in stable, 1.1-7 in pre-release, and 1.3-1 in unstable,
apt would choose by default to install 1.1-7.  If I decided that I wanted
to install unstable's foo, I could just tell apt to install unstable/foo
or if I wanted to always track unstable's foo, I could add that one
package to the list of packages to always get from unstable.


Extending apt and other tools this way would be nifty, but it'd be one
hell of a job for whomever was writing it.  (It'd be damned cool when
finished though!)  Still, even leaving all of this out of the picture, the
mods to dinstall that are required aren't likely to happen.  Since I
believe this to be the case, I can only suggest the compromise of doing
the work by hand on a smaller scale as needed.


> 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.

I cite Slink's freeze time in proportion to its development time.  Also
that Slink was kept from most of the major updates that would have
elongated its freeze time.


> 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'll respectfully disagree with you on this one.  While too often details
are sparse, I find that the same problem develops when they're not.  You
can try to prove me wrong, but I'd rather see quicker releases than being
seeing myself proven right by another dragged out release cycle because a
number of people think they can get it right next time.


> 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.

The problem is, this is what I've seen proposed before.  And everyone
agrees it's a good idea, though a few people from the pools camp say it's
not likely to work.  Someone then immediately points out that pools can't
be ready in time for the next release on this proposed fast-track release
plan and the majority of developers agree to hold off on pools for the
next release and use this quick-freeze development method for the
immediate one (at this point that'd be woody..)

The pools idea gets tabled, a few of us from the pools camp shake our
heads sadly and hope that maybe this time the release will happen the way
others propose.  Announcements are made, deadlines are set, and people
upload everything at the last minute.  Either the deadline gets pushed
back out of necessity or the freeze happens and work begins fixing the
last minute problems.


As soon as freeze finally happens, new bug reports are pouring in
literally by the hundreds and the distribution isn't going anywhere for
quite some time.  It's happened before, three times that I have been here
to see.  I showed up just about time to see Jim Pick ask how many more
months would we be stuck behind Red Hat with our glibc release (8 months
before it was released, as netgod and my sigfiles can both attest)..  It
happened again with slink and then it's happened again with potato.

Do you really think it will be different this time?  If you can honestly
look back at the past three releases and figure out where their release
cycles broke down and find ways to prevent them from happening, I will
fully support any plan you can come up with (not that anyone listens to me
anyway, but still..)

The best I can do, and the best several others can as well it would seem,
is to suggest package pools.  But it really doesn't look like such are
likely to be implemented soon, so PLEASE feel free to find another way to
fix the breakdowns we've had so we can make stable Debian worth using,
even on new hardware Slink (and even Potato before release!) do not
support.

-- 
Joseph Carter <knghtbrd@debian.org>               GnuPG key 1024D/DCF9DAB3
Debian GNU/Linux (http://www.debian.org/)         20F6 2261 F185 7A3E 79FC
The QuakeForge Project (http://quakeforge.net/)   44F9 8FF7 D7A3 DCF9 DAB3

I can just see it now: nomination-terrorism ;-)
        -- Manoj

haha!  i nominate manoj.
        -- seeS