Differences between revisions 32 and 33
Revision 32 as of 2013-12-10 17:27:15
Size: 7510
Editor: shawnlandden
Revision 33 as of 2014-04-23 17:02:37
Size: 7578
Editor: kamalmostafa
Comment: added 3.13 table entry
Deletions are marked like this. Additions are marked like this.
Line 38: Line 38:
|| 3.13 || 3.13.11 || April 2014 || April 2016 || Kamal Mostafa ||

Stable Kernel Updates

The Ubuntu Kernel Team provides git branches available to the greater Linux community which provides stable patches for certain versions of the Linux kernel, when upstream stable support drops off. It forks the latest upstream stable release (with the exception of 2.6.32+drm33 releases, which are a special case).


The repository with stable linux branches is available at git://kernel.ubuntu.com/ubuntu/linux.git (web interface: http://kernel.ubuntu.com/git?p=ubuntu/linux.git). These are the relevant branches:


tracks the Linus master tree


stable tree for linux <version> release, final patches releases go to this


last release of stable tree for <version> release, with patches on top that are to be released with next <version> stable update


last release of stable tree for <version> release, with patches on top ready to be released with next <version> stable update, but which are on release candidate status (waiting any complaints or potential fixes before being released)

<version> is the linux stable series the Ubuntu Kernel Team provides stable patches for. 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.


All patches for the stable releases maintained by the Ubuntu kernel team 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 Ubuntu 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 maintained versions by the Ubuntu kernel team (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 Ubuntu kernel 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 Ubuntu Kernel Team (UKT) provided, provides or plan to provide with stable patches support

Linux Version

Last Upstream Stable

Start of UKT support

End of UKT support




April 2014

April 2016

Kamal Mostafa



December 2013

August 2014

Luis Henriques



May 2013

August 2014

Kamal Mostafa



November 2012

March 31st, 2014

Luis Henriques



when upstream stable (DD Ben Hutchings) drops 3.2.y series

April 2017




when upstream stable drops 2.6.32.y series/already on lookout for drm fixes for 2.6.33 as it's unsupported upstream now

April 2015

Stefan Bader

* Currently 2.6.32+drm33 is maintained as a special case and the repository and other details diverge from what is described in this page


We provide regular debian package builds of the repository contents with the stable patches. These are the current builds being provided, from the versions maintained above:


Builds of the linux-3.11.y-queue branch


Builds of the linux-3.11.y-review branch

http://kernel.ubuntu.com/~kernel-ppa/mainline/ {v3.11*-saucy}

Builds of the v3.11.y.z released tags


Builds of the linux-3.8.y-queue branch


Builds of the linux-3.8.y-review branch

http://kernel.ubuntu.com/~kernel-ppa/mainline/ {v3.8*-raring}

Builds of the v3.8.y.z released tags


Builds of the linux-3.5.y-queue branch


Builds of the linux-3.5.y-review branch

http://kernel.ubuntu.com/~kernel-ppa/mainline/ {v3.5*-quantal}

Builds of the v3.5.y.z released tags

We also provide builds for other stable releases, as can be seen 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


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.

Kernel/Dev/ExtendedStable (last edited 2016-07-13 18:58:46 by kamalmostafa)