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

Re: bits from the release team

On Tue, Jan 03, 2006 at 11:27:25PM +0100, Sven Luther wrote:
> On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote:
> > (forgot to CC d-kernel on this)

> > On Tuesday 03 January 2006 22:02, Sven Luther wrote:
> > > We will have a kernel which is outdated by two versions at release time
> > > with this plan, since there are about 1 kernel upstream release every 2
> > > month.

> > 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just 
> > starting to get implemented).

> > I remember we did consider using 2.6.10 instead of 2.6.8 and decided not 
> > to mainly because it was not really that much better than 2.6.8.
> > As I remember it, this was a joint decision by the kernel team, release 
> > managers and the d-i developers. Not something that the kernel team were 
> > really pushing and was blocked by some assholes from the d-i team who did 
> > not want to cooperate.

> Well, i remember joeyh vetoing it because it would take at least a month to
> get the change done, and i believe we didn't really push for it because the
> infrastructure was a mess back then. This has changed.

> The one point that put me up, is that we should have gotten that security
> update in, but this was also vetoed for the same month-long delay in the
> kernel/d-i upgrade process. The kernel team has reduced that delay to less
> than 24hours now for the release arches,

You have been harranguing the ftp team to approve new upstream kernels
through the NEW queue before they've even been uploaded -- for an amazing
false optimization that burns good will with your fellow developers.  Even
if udebs *were* being built from the same linux-2.6 source package, this
doesn't address the real reason why it's important to freeze the kernel
early:  *the kernel is a core component of everyone's system and detecting
regressions takes a long time*.  Anything that requires a reboot cycle or an
installation test in order for users to detect bugs is going to need a
longer testing period than other packages; the only way to ensure this
happens is by freezing it early, i.e., around the same time as the toolchain
packages for which we have the same problem of figuring out whether a new
version is better or worse.

The underlying assumption in your plea for a shorter kernel freeze is "newer
is better".  But people who accept this assumption unconditionally don't
*run* Debian stable; so neither should we base our freeze timeline on an
unconditional acceptance of it.  Newer isn't necessarily better, but it is
necessarily *different*, which is the enemy of stability.

There is still room for targetted fixes to the kernel after the freeze date;
backports of new drivers, or backports of specific bugfixes, are certainly
fair game.  Taking a new version of whatever upstream happens to have
released would not be.

> My believe is that this kind of thing should be as much automated as possible,
> to let the few ressource we have be used where best it should, a little work
> at the start which will pay off forever after, this is what computers and
> programming is for, to make the task of the users and programmers easier, i
> think we all agree with that, or we would still be using boot-floppies :)

I'm all in favor of streamlining the integration of new kernel versions into
the installer, but I don't believe that the majority of the work involved
falls into the "automatable" category.

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

Attachment: signature.asc
Description: Digital signature

Reply to: