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

which kernel version for etch?

Fellow Debian kernel team members,

let's take the recent "bits from the release team"[1] as an opportunity
to start discussing which kernel version we, the Debian kernel team, 
want Etch to release with.

In these "bits", the release team suggests we have a closer look on
2.6.16, which is very likely to get long-term support from upstream.
To start with, please have a look at the threads starting with [2] 
and [3].

Considering the current upstream 2.6 development model on one side, 
and Adrian Bunks intention to maintain 2.6.16.x for the next 2-3 years 
on the other side - backporting drivers and other updates like the 2.4 
line is handled -, makes the 2.6.16.x line an ideal candidate for the 
purpose of a release kernel for Etch.

One major issue is currently open for 2.6.16: ppc/PrEP support.
Finding a solution for this is a show-stopper, if we want to go the
2.6.16.x path.
The second show-stopper is (IMHO) the missing sparc niagara support, 
which was added in 2.6.17-rc. 
Another issue is smp-alternatives suport, which is available for i386 in
2.6.17-rc, and might become available for amd64 too, soon.

If these issues (and possibly other we might encounter until the release) 
are going to be adressed, I think we should indeed focus on 2.6.16.x for 

This has some implications, though:

First, I would not like to have only a 2.6.16.x kernel in unstable for 
the time being until Etch is released, read until at least the end of 
this year. 

A possible solution could be: 

- branch the current linux-2.6 package into a new source package, say 
  linux-2.6.16, tracking 2.6.16.x releases 

- do the usual 2.6.x development in the existing linux-2.6 package,
  which probably should not migrate to testing until the release is 

Second, if we go this path and do an Etch release with 2.6.16.x, 
I would like to NOT stick forever with that very version we will have in 
testing at the day the freeze happens, but keep updating the kernel 
images and the installer for every point release to a reasonably newer
2.6.16.x upstream release. 
This would ensure more and new hardware support with every point release, 
avoiding one of the biggest drawbacks we currently have with the ancient 
2.6.8 in Sarge.

Security updates for Etch could just ship the latest 2.6.16.x release
which fixes the respective issue, diminishing both the work needed to 
backport the fix and the time our users have to wait for it.

Also, in order to add new minor releases to a stable 2.6.16.x package, we 
need to handle ABI changes in the stable kernel, which means rebuild and 
maybe patch all concerned third-party modules included in the release.

Best regards
Frederik Schueler

[1] http://lists.debian.org/debian-devel-announce/2006/05/msg00000.html
[2] http://lkml.org/lkml/2005/12/3/55
[3] http://lkml.org/lkml/2006/3/20/90


Attachment: signature.asc
Description: Digital signature

Reply to: