[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2.4.0!


On Thu, 25 May 2000, Joseph Carter wrote:

> Date: Thu, 25 May 2000 23:00:37 -0700
> From: Joseph Carter <knghtbrd@debian.org>
> To: Mike Bilow <mikebw@colossus.bilow.com>
> Cc: Erik <journey@jps.net>, debian-devel@lists.debian.org
> Subject: Re: 2.4.0!
> Resent-Date: Thu, 25 May 2000 22:58:56 -0700
> Resent-From: debian-devel@lists.debian.org
> 
> On Fri, May 26, 2000 at 01:24:18AM -0400, Mike Bilow wrote:
> > I disagree with this.  I think, as I said emphatically and repeatedly,
> > that the solution is more frequent full releases and shorter release
> > cycles.  I would ideally like to see Woody release about six months after
> > Potato.  I think the Potato release should be followed by about three
> > months of aggressive integration of new packages into Woody and then about
> > three more months of freeze and testing leading to release of Woody.
> 
> 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.
> 
> 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 think about it, both of these schemes boil down to the same
> prospect:  Adding packages as they become stable to an already stable
> distribution.

The only way to do this in a safe manner is to do what I proposed in my last
e-mail to the list.  We start with a base, which we all show to be stable, and
work off that.  The layered approach could let us release a new BASE every three
months.  The apps that sit on top of that one can then be set on the new base,
and tested, in order of their dependancies on other packages(the fewer
dependancies it has, the quicker it can be added and tested).  At any time,
people can upgrade, first the base, then the layers as they are tested.  There
are SOME problems with this approach(like the new base POSSIBLY killing your
apps), but that's the price of working with an unreleased version of the OS.  It
would probably be as safe as what people have done when using unstable in the
past, but at least MOST of your system will be stable.

							Dave Bristel
 

 
> 
> 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.
> 
> 
> > This would guarantee that nothing would be more than three months behind
> > when the release is declared stable, and also would make it more likely
> > that packages could be pulled individually from unstable and used on
> > stable (by users who need to do that) because there would be much less
> > distance between stable and unstable.  Almost no Potato packages work on
> > Slink now, since there are such wide variations in libc6 requirements and
> > all sorts of other pervasive things.
> > 
> > I regard it as unwise to upgrade major components which touch everything
> > (such as libc6, xfree86, or gnome) separately without extensive testing.
> 
> 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.
> 
> -- 
> 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
> 
> <rcw> those apparently-bacteria-like multicolor worms coming out of
>       microsoft's backorifice
> <rcw> that's the backoffice logo
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: