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

Re: Preparation of the next stable Debian GNU/Linux update

On Sun, Jul 27, 2008 at 07:22:21PM +0200, Frans Pop wrote:
> >> New package loop-aes-etchnhalf:
> >>  architectures in updates: s390 all amd64 i386 powerpc arm sparc alpha
> >>  ia64 mips mipsel hppa version in updates: 3.2c-2~etchnhalf.2
> >>  Rationales:
> >>   - 3.2c-2~etchnhalf.1: loop-aes-etchnhalf - source compatible w/
> >>   etchnhalf kernel

> > As linux-modules-extra-2.6-etchnhalf was not ready in time we decided to
> > skip it for r4 and include it in r5.

> Well done folks. You've again managed to break at least part of the 
> functionality of Debian Installer and, more importantly, left users with 
> a potentially unbootable system after installation.

> This is the third time since Etch where a stable release involving 
> something I have spent a serious amount of my time on is mishandled by 
> the release team.
> I've had it with this mentality where apparently it is OK to just skip 
> proper and timely preparation of releases, where it is OK to do things at 
> the very last possible moment, break promises made to colleague DDs and 
> break their work without any prior communication at all.

So you would have had the release team do what instead, exactly?  Wait
indefinitely for this package to be ready, even if that meant impacting
lenny preparations or releasing etch-and-a-half after the lenny release?

The value in doing a ½ style point release is to make the OS available to
users of newer hardware.  If the point release is delayed so long that
there's a new full release out before it's done, then *no one* gets the
benefit of being able to install a supported Debian release on hardware that
wasn't supported before.  How would *that* be showing appreciation for the
work that people have done to make etch ½ happen, exactly?

Releasing without linux-modules-extra-2.6-etchnhalf et al. means that the
updated hardware support is still useful to *some* users with newer

As a release management decision, I see no grounds for attacking the release
team the way you do.  The normal media are still useful the same way that
they were before, and the etchnhalf installer option is more useful than not
having one was.  That looks like a success to me, albeit a qualified

On "breaking promises" and "without any prior communication", I have no
idea.  I agree that neither is a good thing, but in my following of
debian-release and debian-boot, I frankly have no idea where promises were
made and broken.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Reply to: