hey,
Frans Pop assembled an informal BoF at DebConf to discuss cross-team
issues related to the kernel[1]. Attendees included:
Micah Anderson (micah)
Andreas Barth (aba)
dann frazier (dannf)
Joey Hess (joeyh)
Moritz Muehlenhoff (jmm)
Frans Pop (fjp)
Manoj Srivastava (manoj)
...and a few other folks whose names I don't recall
We discussed the following topics:
* Which kernel to release with Etch (2.6.16 from AB or "current"
upstream)
* Kernel Updates during Etch Lifetime
* Dropping 2.4 from Etch
* Non-free modules + firmware
* External module packages
* Divergence Between linux-2.6 packaging and kernel-package behavior
* Kernel udeb creation process (possibly using k-p?)
This report is based upon notes I took during the meeting, and my
recollection. Neither will be completely accurate; and no statements
attributed to an individual should be taken as a direct quote.
Which kernel to release with Etch
---------------------------------
This discussion is related to a thread[2] on debian-kernel about which
kernel we will choose for etch.
Attendees expressed concern over choosing to move to a new 2.6.x
release shortly before etch releases - a kernel that has has a few
2.6.x.y releases would be preferred.
With respect to using the Adrian Bunk tree, attendees expressed
concern that this tree is unproven. It is possible that Adrian has
underestimated the amount of energy it will take to maintain such a branch.
Success of this tree may depend upon the assistance of its consumers
(such as Debian).
It was noted that even if we stick with 2.6.16.x, the kernel team will
still need to limit ourselves to cherry picking patches once we
freeze, otherwise we may pull in new features/ABI breakages after the
freeze.
The current release schedule[3] has us freezing the kernel by July
30th. However, aba noted that the kernel freeze is really just a
dependency of the d-i schedule. According to Frans, a kernel freeze
of October 1 is necessary for d-i's final release candidate to remain
on schedule.
Andi noted that if we change the kernel later than mid/end July we'll
need to do more extensive testing of the sarge->etch upgrade than usual.
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.
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.
We wouldn't want an etch 1/2 kernel that requires a large number of
changes to userspace packages.
Questions about X update issues were brought up; but Frans doesn't
think that will affect d-i. What about alsa?
We should have a formal agreement about how we *would* do an etch & a
half ahead of time so we can make sure d-i has any features it should need.
This should probably be discussed on -devel to get project-wide buyoff.
Frans thinks d-i can make necessary changes in a max of 2 months, but it
depends upon what other things may be going on at the time (etch+1
betas, etc)
We could make test d-i images available for "stable" like we currently do for
"testing". We probably don't need the extreme testing as for the first
release.
jmm, dannf & frans all seem to agree that we should use the etch
kernel as the default boot kernel, even after a etch 1/2 kernel is added.
jmm wondered if there ways we can limit our security load for an etch
1/2 kernel? We could just claim security support for our build, not
the entire kernel-source (for etch+1/2) - or maybe a reduced
maintenance time, like etch + 1 + 3 months.
frans asks if its possible if minor versions could be accepted in a stable
release. aba responded by saying the RM's policy is that any bug
important or greater should be fixed, even in a stable release.
dannf asked what the stable-RM policy is on doing driver updates, etc,
in the stable kernel (separate topic from a possible etch 1/2).
aba said that this may be acceptable if the changes are pretty limited
(only affects a given driver), and should be discussed on a case-by-case basis.
Manoj suggested a kernel diversion possibility for module-specific updates.
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.
Non-free modules + firmware
---------------------------
It was noted that Bastian Blank is working on splitting non-free
modules out of main into their own source package.
frans> It should happen pretty soon; we need the modules in non-free before
we do the d-i work; d-i will probably ask for an exception so that
d-i can install them as though they were in main because frans thinks
we won't have time for that (modules really won't be in main)
This means that non-free modules will be on installer cds. The needed
exception would be to allow etch to be used as a transition period.
manoj> this isn't a release management decision, we don't want another GR
aba> a GR would be time consuming
manoj> what about a free and a non-free installer image, where the non-free
installer is in the non-free section
aba> 2-3 different options
* images like today w/ non-free udebs
* only put the modules on non-free, make users pick them up
* dropping support for devices that require non-free fw completely
manoj> only option (for permitting non-free modules on the etch
installer) is a gr to once again modify our social contract
suggestion was made to have users "click-through" to opt-in to use non-free
firmware. manoj believes this is still a violation of the social contract
and will require a GR (because the non-free modules would still be on
the media)
manoj> you can ask for an official interpretation of the social contract
from the project secretary.
manoj suggests two different installers, but joeyh is concerned over additional
maintenance/support
The deliver modules/users opt-in approach would give us enough time,
but requires a GR.
joeyh> maybe keep it as a separate image that can be combined by the user,
problem is that the solution varies with each installation method
floppy install needs another floppy; netboot needs another layered
initramfs
joeyh> multi-sessions could be used for cd installs
In conclusion, we believe the following options exist:
a) debian doesn't support this hardware
b) GR to allow combining
c) make users combine
External module packages
------------------------
Its believed that if we solve the non-free external module package
issue, we will also have solved this one.
- divergence between official kernel packaging and kernel-package (k-p)
The /lib/modules/$(uname -r)/build symlink issue was introduced by
Manoj. The attendees agreed to move this to a discussion thread on
debian-kernel, in probably a week's time.
Kernel udeb creation process (possibly using k-p?)
-------------------------------------------------
If we build all of the *existing* udebs from a single source, we outgrow
the limit of the Binary: field in the control file.
A second limitation exists in sarge's version of apt, which is what we might
be running on ftp-master. Not an issue if we start this with etch + 1
this will create an upgrade problem for users.
buildd issue - it'd be nice if we could be from an unpacked kernel, but you
can't build-dep on that so its a FTBFS.
udebs/deb creation is currently separate - is that a feature?
svenl has noted that a porter has to select modules twice - during the
kernel build and during the udeb creation
manoj wonders if maybe kernel-package can do this work. he wouldn't
want to build the per-arch mapping into k-p, but might take these from
lists on the file system
joeyh notes that kernel-wedge could also support this additional functionality
Frans points out that his preference is to continue to keep udeb
generation separate from the mainline kernel, to avoid having to do a
full kernel release each time we shuffle udeb contents.
Frans believes that sepearate source packages are more feasible for allowing
this type of shuffling
dannf suggested that maybe k-p can be configured to allow simple unapcking of
debs vs. all the postinst configuratin to allow autobuilders to deal with udebs
better; manoj thinks that this will be possible but further out in the current
k-p transition that allows for users to do more "overriding" of
postinstallations by default.
manoj> new kernel package will have some new features the kernel team might like
- versioning is messed up, manoj is integrating abi number, etc, into k-p
dannf> what if we split up centralized udeb source packages to manage a certain
set of archs
The consensus was that the current udeb approach is suboptimal, but
solving it cleanly won't be possible until etch+1. None of the
attendees considered this issue to be critical for etch, so the
current plan is to status quo and wait till etch so that we can come
up with a good solution.
[1] http://lists.debconf.org/lurker/message/20060517.065113.4f39d60e.en.html
[2] http://lists.debian.org/debian-kernel/2006/05/msg00130.html
[3] http://lists.debian.org/debian-devel-announce/2006/05/msg00000.html
--
dann frazier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
