There is a tension between the desire to minimise updates to released products (as enshrined in the SRU process) and the desire to provide ongoing hardware enablement within a release. This tension is particularly acute with LTS releases which have extremely long support periods.

As a compromise it is proposed that in addition to the default kernel in an LTS release we would provide new packages containing kernels from each of the regular releases after the LTS upto the following LTS (this asumption is subject to debate). These would be provided such that any of them could be installed on the LTS without collision with the other installed kernels. These kernel backports are intended to satisfy hardware enablement needs in the server space. Desktop users are required to use a recent release, especially for graphics and wireless improvements.

During the Karmic cycle we showed that this could be viable by producing a Jaunty kernel (in PPA) for Hardy and demonstrating that it could co-exist with userspace. During the Karmic and Lucid cycles we developed the kernel packaging such that we can more simply modify handle multiple coexisting kernel source packages. This work was used to handle the ARM variant kernels.

Release Note

No release note would be meaningful for Maverick, no user visible changes would be present in Maverick for this feature.


Our SRU process is designed to contain the risk to the existing user base. Its aim is to limit changes in the release to those absolutely required to fix bugs and regressions which are being experienced in the field; this nominally excludes changes purely for hardware enablement.

This constraint is in direct tension with the aims of an LTS release which aims to provide a consistent userspace environment across all hardware in an installation. As new hardware is brought into the environment it is likely that that hardware will not yet be supported by the LTS kernel. This leads to an effective exception to the SRU process for LTS releases allowing hardware enablement changes into the LTS kernel. This introduces extra risk into the LTS release for all users of that release, the place where risk is by definition least desirable.

If we could offer a range of kernels on LTS releases older machines could be maintained on the existing default kernels, whereas newer machines could run the kernel most appropriate for them. This would allow the original LTS kernel and subsequent release kernels to have normal SRU policy applied in equal measure. Whilst allow those machines which really need a later kernel to obtain hardware support, and in a supported and supportable manner.


We are assuming that we could pull back kernels and their direct dependancies back from later releases and make them available in such a manner they would not conflict with the current kernels either in the archive or once installed. In order to reduce the need to pull back large numbers of depdancies care would be exercised to ensure that userspace kernel compatibility will be maintained between releases which need to be backported.


For an LTS release N, we would plan on packaging the kernels from release N+1 (M) for that LTS release. This would involve renaming the source package to linux-M. This would allow these to install in parallel with the original kernels and also avoid collisions within the archive. These would be uploaded as normal into the LTS -proposed queue (and migrate as normal to -updates); this would ensure that the kernels are built with the appropriate compilers for the release.

Maverick Kernels for Lucid

The first practicle backport kernels will come from Maverick back into the 10.04 LTS (Lucid). The kernel Maverick kernel package will be used as a base with modifications to rename it to linux-maverick and to move it to the lucid series. This will be maintained in a similar manner to a topic branch against the maverick kernel.

Test/Demo Plan

The first step will be to provide a Maverick kernel built for lucid in a PPA, built against the lucid userspace. This will allow compatibility testing on Lucid prior to release of Maverick.

BoF agenda and discussion

Discussion Notes

discuss plans for backporting newer kernels back to LTS releases

Naming of meta packages in the archive -

* force manual upgrade between release, no meta package to automagically upgrade * for each LTS point release, there will be an intall option to use these newer kernels

* purposely focusing on the server space to hopefully avoid userspace conflicts

* the lucid-maverick branch will live in the lucid repo * intend to have a PPA relatively soon providing maverick kernel for lucid

* need to coordinate with QA to re-certify for servers * work with kirkland and server team to work out UEC * which flavours will we roll back?

* ensure you always remain in for ex -generic as we update * figure out how to do release updates/upgrades when running an updated kernel * source packages need to be versioned ~<release>N

* fix apport to report you're running a backported kernel

Final Resolution


KernelTeam/Specs/KernelMaverickNewKernelOnLTS (last edited 2010-05-17 12:19:18 by apw)