This document is intended to document the processes involved in the maintenance of stable (after release) kernel trees. Those should be independent of a specific release. If not, this should be noted on the specific description.
Post-release updates
The vast majority of fixes to released Ubuntu kernels come through the upstream stable fixes process. A minority of fixes originate from Ubuntu developers. Any fixes originating from Ubuntu developers should be submitted upstream, so that the entire Linux community will benefit.
Updates to the upstream stable trees are automatically considered for inclusion in Ubuntu Stable Release Updates (SRUs).
Please see UpstreamStableKernel for more information about that process.
SRUs/bugs
Stable release updates will be done after the initial release. To prevent regressions there are a more formal process involved in getting new patches included. The process is described in general at StableReleaseUpdates with a kernel specific part described KernelUpdates.
Every SRU needs a bug. Patches are sent to kernel mailing list and have to get at least two ACKs from other senior kernel developers (those in the kernel_cdev group on zinc).
- All patches should be signed-off-by the person who did the patch. The developer who is committing the final patch, also needs to add his SOB.
Patches from upstream should not change the submitter's reference. They should be cherry-picked or exported and then re-imported (git format-patch and git-am. Personally I do a
git format-patch -s <sha> -1
then add bug and/or CVE references and then import the resulting patch (the -s automatically adds a signed-of-by line).- Changes that require an kABI bump should be marked by adding "BumpABI: yes" to the git message. This is a manual process but makes life simpler of someone asks why the ABI has been bumped.
- SRU justification is added to bug report and nomination for releases are used to track progress for each release (if appropriate).
- ubuntu-sru has to get subscribed
- The milestone is set for the next official update release only for bugs that are important (iow when you want to be chased by a release manager if that patch fails to get included).
CVEs/security updates
See: HowTo: Fixing CVEs
Versioning
Signed modules (circa 2016) require every release to bump the ABI. The following discussion is retained for historical purposes:
A general rule is that the security release has to be a higher version/release number than anything else. This causes some headaches if there is a proposed version not yet moved into updates, especially if this is an ABI bumper.
- If there is no kernel package in proposed, the security release just gets the next release number. Should the security release require an ABI bump, this is also done like normally.
- If there is a kernel in proposed, the security release gets the next number that would follow it.
- Should this proposed kernel be an ABI bumper, then the security release has to match that ABI number and the rebuild of proposed needs to bump the ABI again.
- Should the proposed kernel be an ABI bump and the security release is also an ABI bump, the security release must bump the ABI and upload number of the kernel currently in proposed.
The following examples try to illustrate the version handling:
Updates: 1.1 --+-------------------------+-- Proposed: \-- 1.2 -------+-- 1.4 --/ Security: \-------- 1.3 / Updates: 1.1 --+--------------------------+-- Proposed: \-- 2.2 ---------+-- 3.4 --/ Security: \-------- 2.3 --/ Updates: 1.1 --+----------------------------+-- Proposed: \-- 2.2 ----------+-- 4.4 --/ Security: \--------- 3.3 --/
In any case where there was a proposed kernel pending and it has to be rebuild with the security patches included, the changelog will be modified to include all changes that have been recorded by proposed uploads which have not been moved to updates, as the new release and the old ones get dropped. Here an example. Given there have been two uploads to proposed accumulated but not moved to updates. The changlog would look like this:
linux (2.6.24-1.3) hardy-proposed ... - item 3 linux (2.6.24-1.2) hardy-proposed ... - item 2 - item 1 linux (2.6.24-1.1) hardy ... - in updates
Then a security release comes and takes precedence. After that has been released we prepare a new upload to proposed and the changelog looks like that:
linux (2.6.24-1.5) hardy-proposed ... - item 3 - item 2 - item 1 linux (2.6.24-1.4) hardy-security ... - security update linux (2.6.24-1.1) hardy ... - in updates
Updates to custom binaries (virtual/openvz/...)
Custom binary builds are usually community maintained and not as critical as the main kernel flavours. Nevertheless updates should follow a certain pattern to be clearly documented.
- Get triggered by a community member (usually kernel-team mailing list)
- Open a LP bug for SRU documentation
- Create a branch and pull/cerry-pick
- Do a test build
- Publish the SRU request on the kernel-team list. References to patches as gitweb links since patches might be big.
Test builds
Either in a PPA or on the porter machines. HPPA is a problem due to hardware access.
Release
See: Howto Release A Kernel Update
The actual release
The release is done by uploading the source packages to the kernel team ppa. Once it has been built, it get's pocket copied from the ppa to the -proposed pocket. If the kernel ABI has changed, LUM, LBM and LRM must be uploaded with updated version/ABI numbers as well. Also the linux-meta package must be updated and uploaded (after the other packages are done).
Post-release tasks
As described in KernelTeam/KernelMaintenance. Thoughts on that:
- The ABI files have to be fetched when starting a new release. The maint-startnewrelease script can be used to fetch the ABI files from the builders.