• Launchpad Entry: kernel-karmic-sru-policy-review

The current SRU policy with respect to the kernel is a bit fuzzy, and in my opinion isn't working too well. The basic rules are thus:

• A patch (or related patch series) must fix a specific problem and must have an associated Launchpad bug.
• A strong preference is given to upstream cherry-picks.
• All patches must have an ACK from at least 2 senior Canonical kernel devs, i.e., those developers with git repository commit rights. Developers cannot ACK their own patches.
• The kernel must bake in -proposed for a minimum of 7 days. All Launchpad bugs associated with that upload must have positive test results (as well as no regressions) before it can be promoted to -updates. In practice, promotion to -updates only occurs about once per quarter.

The kernel team abuses the SRU policy in the extreme by periodically applying updates from the upstream stable kernel. It is simply impractical to file and track a Launchpad bug for each stable update. Therefore we've adopted the policy of one Launchpad bug for each stable update series. For example, 2.6.27.y has had 22 update series for a total of 987 patches.

Furthermore, the kernel team has an agreement with the SRU team that they will apply stable updates for only the first 4 months of a non-LTS kernel. LTS kernels get stable updates for as long as there are updates.

In my opinion (rtg) the size of the kernel and the volume of patches make it impractical to subject it to SRU policy in any meaningful way. I'm beginning to think that we should adopt a Rawhide model of kernel development. How about this:

• Once a kernel is released, it is never patched except for CVEs and OMG kitten killer bugs.

• Immediately after release the kernel is forked in a new git topic branch with a new ABI and retargeted for -backports. Of course any patches applied to the master branch are cherry-picked into the -backports branch.
• The kernel team continues to use LP to manage bugs against the -backports kernel, but none of them are milestoned.
• Stable updates are applied to the backports kernel for the life of the updates series.
• Backports kernels are uploaded at will.
• Approximately a month before the next release, a new kernel repository is cloned from the existing -backports branch into a master branch and rebased against Linus'.
• All development effort is refocused on the next release kernel.
• Rinse and repeat.

To me (smb) this is playing around with names. Effectively that backports kernel would be updates and the updates kernel like security. Only that updates and security are lacking any other improvement which forces users to use a maintained but unsupported kernel. Also I don't see this saving much work. I would rather like to see it agreed that the kernel requires a slightly more open SRU approach and better define the deviations.

• Non-working hardware is a valid kernel problem to me. Though this has to be restricted to the currently released kernel and to the latest LTS. The fixes must be simple so their risk to cause regressions is minimal (if not zero).
• We should probably put more emphasis on upstreaming. So fixes that are not critical would only get accepted if there is a upstream accepted counterpart.
• The general SRU policy requires a fix to be first tested in the development series and only if that is successful, it might get backported. This is a problem with the kernel, as not every user wants to upgrade into a development system to verify a fix. But we should let them verify a bug exists there (with a live CD).

Summarized new policy

(if we finally agree, we should move that to out documentation)

• Only patches that are upstream will be accepted. The only exception would be fixes for highly critical problems that must be fixed and upstream has not yet accepted / agreed on the fix or will fix the problem differently.
• We stop pulling in stable release patches in bulk. Only individual patches will be pulled if there is a bug report for it. That goes for normal releases as for LTS releases.
• The first step will always be to verify the problem against the latest daily build kernel.

Acceptable patches

• Patches that fix critical or high problems (Oops, Panic, data loss, CVE)
• Fixes for regressions caused by the current release depending on the size and complexity.
• Hardware enablement patches are only acceptable in the form of quirks or ID additions and only until the next release has reached beta status. For LTS releases this is allowed for the lifetime of the release.
• The stable maintainer can choose to pull in individual patches if those will add to the user experience and have low regression potential.

Process

• A patch (or related patch series) must fix a specific problem and must have an associated Launchpad bug.
• All patches must have an ACK from at least 2 senior Canonical kernel devs, i.e., those developers with git repository commit rights. Developers cannot ACK their own patches.
• The kernel must bake in -proposed for a minimum of 7 days. All Launchpad bugs associated with that upload must have positive test results (as well as no regressions) before it can be promoted to -updates. In practice, promotion to -updates only occurs about once per quarter.