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 Etch. 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 done. 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 -- ENOSIG
Attachment:
signature.asc
Description: Digital signature