Extended Stable (the -ckt kernel series)

The Canonical Kernel Team ("-ckt") provides extended stable support for certain versions of the Linux kernel, in the form of git branches available to the greater Linux community. These versions start from the last upstream stable release after upstream support ends.

Repository

The repository with stable linux branches is available at git://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt (web interface: https://git.launchpad.net/~canonical-kernel/linux/+git/linux-stable-ckt). These are the relevant branches:

<version> is the linux stable series for which the Canonical Kernel Team provides stable patches. See the Version Matrix section for more information.

New Releases and Announcements

New releases of stable patches will be announced at kernel-team@lists.ubuntu.com, the linux kernel mailing list (lkml) and the stable mailing lists.

We will have a cadence of 1 to 3 weeks for new releases (that is, each 1/2/3 weeks if there are patches in the queue they will be put into a release candidate status, and if nothing is wrong after 2/3 days they will be released). For the release/maintenance process, see Maintenance below for more information.

For some releases, emails being sent for notifications or announcements should have the field X-Extended-Stable, an option for people that want to do filtering on received emails.

Contributing

All patches for the -ckt stable releases should be submitted upstream, following the stable upstream acceptance rules (see Documentation/stable_kernel_rules.txt in the upstream kernel source tree for more information).

The Canonical Kernel Team should monitor and pick the relevant stable patches automatically once they are released with upstream stable. In case that not happens, or the change/patch is only applicable to one of the -ckt stable versions (in the case the patch isn't relevant to any of the current stable kernel versions being maintained by upstream, for example when a Cc: stable@kernel.org isn't applicable anymore), you can contact the team at kernel-team@lists.ubuntu.com requesting the patch to be applied. Of course the patch must conform to the stable upstream acceptance rules in the second case.

Version Matrix

This is the table with status of linux kernel versions that Canonical Kernel Team provided, provides or plans to provide with stable patches support

Builds

We provide regular debian package builds of these stable releases at http://kernel.ubuntu.com/~kernel-ppa/mainline/.

Also, some builds usually are tested using our automated testing infrastructure, the results of the tests can be seen at http://kernel.ubuntu.com/testing/index.html

Maintenance

The maintenance process is more of interest for the person currently maintaining an stable tree, so it's not detailed here. If you are a maintainer, go to Stable Kernel Updates Maintenance. Generically, the process should be like this:

1. Patches not yet included on stable version and marked for stable* are picked up from master Linus tree, and we try to apply them to the linux‑<version>.y‑queue branch:

   • Patches which apply cleanly, should be reviewed. If something shouldn't have been applied/added, discard/remove from the branch.

   • Patches which fails to apply, should be reviewed. If they are applicable to stable linux‑<version>.y, it must be fixed or a request sent out for help with backporting/fixing. The fixed version should be applied to the branch

   • Patches marked for stable but with a restriction for a specific kernel version, should only be applied if they are intended for stable linux‑<version>.y being maintained, in case the patch isn't applicable for it should be discarded.

2. After the cadence period, push the patches from the linux‑<version>.y‑queue to the linux‑<version>.y‑review branch, and announce a review cycle on the mailing lists.

3. After the review period, and with any problems found in review process fixed, push the patches from review to to linux‑<version>.y branch, close and tag the new release with simlar versioning as upstream (as close as possible, depending on the case), and rebase/sync both queue/review branches. Then announce the new release.

* marked for stable means the patch has Cc to stable, or was requested/should be included following the rules on the Contributing section. The same upstream stable rules apply.