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. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
