Planning kernel updates in etch
hey,
I'd like to start a discussion on how we will go about doing
updates to etch after its initial release.
Security Updates
----------------
Security updates will happen in dists/etch-security in svn and I'll
continue to coordinate those. However, I'd love to have some
help/redundancy for this. Very little of the work actually requires
being on the security team or having access to vendor-sec, and the
tracker for these issues scales pretty well w/ multiple people. Please
contact me if you're interested (and/or see the kernel-sec repo on
svn.debian.org).
Stable Updates
--------------
In etch, we should really start taking advantage of point releases
updates to fix bugs.
What bugs can be fixed in a stable update?
------------------------------------------
The stable release team considers bugs of severity important or
greater to be candidates for a stable update. Additional device
support is considered 'important', so low-risk/well tested driver
updates are possible.
What bugs cannot be fixed in a stable release?
----------------------------------------------
The _most_ important thing is that we must not break existing
systems. So even if something fixes an unquestionably important bug,
it may still be rejected because it adds too much risk. ABI changes
are considered high risk.
If you want to get in a fix that is considered too risky for 2.6.18,
your best bet is to get it upstream so that its available for a
possible "etch 1/2 kernel" (see below).
Every commit targeted for a stable update should include a changelog
entry that references a bug report with an appropriate severity. This
makes it easier for the SRM team to review the issue. We should
certainly watch the various stable git trees for updates, but they
should not be treated specially. Each fix we pull in should have a >=
important bug that clearly justifies its inclusion.
Commits should occur under dists/etch in svn (looks like this was
branched already). We'll of course have to merge security updates in
periodically.
"etch 1/2 kernel"
-----------------
As discussed last summer, let's look into adding a new kernel into
etch at some point. I'd personally like to time this to occur about a
year after etch so that we won't be trying to do security updates on
sarge, etch and etch 1/2 all at the same time.
If you want to add support for a new device but its too risky to do so
in 2.6.18, this is the way.
Using usertags to track
-----------------------
In the past we've used usertags to track bugs queued for a stable
update, all under user debian-kernel@lists.debian.org.
dkt-pending-sarge-update: queued for a point release
dkt-pending-sarge-security-update queued for a security update
These are documented on our wiki page:
http://wiki.debian.org/DebianKernelBTSUserTags
There's also a new one added there:
dkg-waiting-etch-update
Which seems to exist for fixes that are queued, but not yet committed.
I propose that we continue using usertags for this purpose, but only
two of them - one for security, and one for non-security.
We can use the 'pending' tag to differentiate between issues that are
fixed in svn and those that are not yet fixed (pending flag is added
automatically by a post-commit hook anyway).
My suggestion is simply 'dkt-etch-update' and
'dkt-etch-security-update'. Neither imply the status of the bug, which
I think is sufficiently handled by other tags.
--
dann frazier
Reply to: