Re: which kernel version for etch?
On Tue, May 16, 2006 at 10:47:50AM +0200, maximilian attems wrote:
> i disagree for the 2.6.16 choice, will point out the args as following.
> * sarge released with an more than one year old kernel
> that was bad as new hardware from the sarge release day on was not
> supported (d-i jump to the vc2 wget newer image and be fine sure,
> but that is not the support d-i customers deserve).
> especially bad as the 2.6.8 acpi was crap, the sata support almost null,
> vm bad under high load or mem pressure, nfs flacky..
>
> 2.6.16 was released on Mar 2006, if the next release gets out of the door
> dec/jan 2006/07 we get this same bad situation of an year old kernel to
> support.
>
... <list of good examples of why 2.6.16 will grow stale> ...
I agree that we are in a bad state with 2.6.8, and there is a
potential that freezing on 2.6.16 will put us in the same state. I've
had a few conversations at DebConf about how we can add a newer
upstream kernel in a stable point release; I'll bring this up in a
separate discussion thread with a broader audience because I think it
is a mostly unrelated discussion[1].
However, to meet the etch release schedule, we need to begin freezing
the kernel relatively soon. I am not sure what those dates are
though; hopefully this will become more clear after the etch release
discussion at debconf on Thursday (iirc).
The bit I find interesting about 2.6.16 is that Adrian Bunk has
proposed maintaining a 2.6.16 branch where new *features* are
permitted, and it sounds more inline with how 2.4 was maintained once
2.5 had forked. If this happens, it *should* provide a more
controlled tree than Linus' from which we can pull in updated features
like atapi, acpi, etc, and continue to sync them into our testing
kernel until the freeze. If we could have trivially cherry-picked
features from 2.6.10 and backported to 2.6.8 before sarge, I think we
would have; but the number of changesets between the two was so
immense that we only really considered moving completely to 2.6.10.
If it turns out that the bunk tree does not receive the feature/driver
updates we want, I agree that it is probably not the right base for
etch. Of course, it may mean that we get to do the backports and
convince Adrian to accept them :)
[1] Unrelated because I think we should be picking the kernel with the
most stable user-desired features that will be available in time to
meet our release schedule, without counting on this possible update
later.
--
dann frazier
Reply to: