On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: > hey, > Frans Pop assembled an informal BoF at DebConf to discuss cross-team > issues related to the kernel[1]. Attendees included: Sorry I wasn't able to make this meeting, guys. Random thoughts: > Kernel Updates During Etch Lifetime > ----------------------------------- > This discussion is based upon the idea of providing an updated kernel > with new hardware support during the etch *stable* release. We've > been referring to this update as "etch and a half". > Would we keep both the etch and etch 1/2 kernels? Yes - we would not > drop support for a stable kernel in a stable release. > 2 months was suggested for user testing of a kernel prior to including > it in a point release. > To enable this possibility, d-i will require some work. > fjp said that, for d-i, the critical udeb is base-install which builds > a list of available kernels and selects a default from that. If a > good default can be found, it will be installed. If no default is > found, it will just show the list of kernels it did find. (With > medium priority it will always show the list, but with the default selected). > base-install selects this default by taking the stem name of the > kernel and the major version (kernel-image-2.4, linux-image-2.6). > How the kernel is named will be very important. What will also be important > is what we expect to run after the kernel has been released. > We want to use the same install kernel as the target, to avoid hitting bugs > late in the install. We would want to add the etch 1/2 kernel to the > installer, and not drop the etch kernel from the installer. > A blocker for d-i would be 2.6.12 -> 2.6.14 style changes (devfs drop). > Frans suggested talking with Marco D'itri (or perhaps GregKH) about planned > udev stability. Moritz is fairly sure that GregKH is planning to keep > a stable interface. Frans says Linus has also mentioned that he > doesn't plan to accept breakages to this interface. This isn't a blocker *just* for d-i. Consider how painful the upgrade path is from sarge to etch on account of the circular dependencies between the kernel, udev, and initramfs generators. This may be something we just have to cope with for sarge->etch, but do you really want to compound the problem by adding etch -> etch 1/2 and/or etch 1/2 -> etch+1 to the mix? > Perhaps we disable new kernel features for etch 1/2? e.g., limit new > feature to new hardware support. For example, we wouldn't want to > turn on something as drastic as preempt in a stable update. So how do you structure this? I would expect that updates limited to new hardware support shouldn't normally change the kernel ABI at all, which makes it hard to make both the old and new kernel versions available for installation. If it is a new kernel ABI (either because the version number has simply been changed on it, or for other reasons), what gets done with out-of-tree module packages? > Dropping 2.4 from Etch > ---------------------- > aba noted that Holger had spoken with him earlier, and asked if it > would be ok to do stable/2.4 maintenance by tracking the latest 2.4 > upstream instead of individual security issues. > dannf noted that 2.4 has poor upstream security support. Rough > consensus was that we cannot support 2.4 in debian for security > reasons. If we drop it for etch, Frans would like to drop 2.4 support > from the installer as well. d-i will become easier w/o 2.4 support, > but only if we drop sarge support in the etch installer. Frans is ok > with dropping this sarge support. I agree with all of this, and had a similar discussion with Holger. With no one stepping up to provide the needed security support for 2.4 in etch, are there any further objections to beginning the process of removing the 2.4 kernel packages from unstable? Will someone on the kernel team be willing to drive this? -- 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