Launchpad Entry: kernel-maverick-new-kernel-on-lts
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.
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.
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
- What is the motivation for this change
- the tension between the SRU process (short lived static releases) and the LTS (long lived releases)
- What is planned
- The first officially backported kernel will be Lucid+1
- Every kernel release after an LTS will be backported, up through the release previous to the next LTS.
- Backported kernels are supported for 18 months, including CVE, SRU, and stable updates.
- A meta package will be created for each backported kernel. The meta package updates will cease at the end of the 18 month support period. There will not be an automatic upgrade to the next backported kernel.
- Only the server userspace will be supported on certified hardware.
- Only x86/x86_64 kernels will be backported.
- How might this work
- we are proposing to rename the source and binary packages to include the source release name and upload those into the LTS release
- these kernels would be essentially identicle to those uploaded into the release from which they come
- probabally with some level of configuration changes
- we would probabally carry them as a M named branch in the M repository as it would be near identicle to that kernel and updated in step with it
- how do we handle the userspace dependancies this might require
- new depancies such as crda needed for a Jaunty kernel
- presumably we would need foo-jaunty dependancies too
- would we try and support binary drivers for these
- some work would be needed to ensure that userspace was maintained compatible with all kernels available on the LTS.
- we should consider starting this in advance using a PPA offering the Mavierick kernel for Lucid; allowing us to see the issues in action
- how long would these released need to be supported
- these new kernels would be supported for the length of support of the master release from which they are made, this gives the consumer time to upgrade up through the next LTS
- how would we handle certification
- clearly the kernel is part of the certification
- we would need buy in from software vendors to handle these new combinations
- how do we handle the userspace dependancies this might require
discuss plans for backporting newer kernels back to LTS releases
Naming of meta packages in the archive -
- linux-maverick linux-NN etc
* 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
- need to ensure it is clearly stated these will only be supported for 18mo
- remember point releases are DVD's only so should have enough room for the newer kernels
* purposely focusing on the server space to hopefully avoid userspace conflicts
- how will we handle userspace dependencies should they arrive?
- need to put a policy in place for worst case scenario (eg there are conflicts)
* the lucid-maverick branch will live in the lucid repo * intend to have a PPA relatively soon providing maverick kernel for lucid
- don't expect anything in archive until weeks after release; roughly in sync in time for the point release
* 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?
- identical to release kernel with exception of the release in the changelog
* 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
- also allows for easier detection for bugs
* fix apport to report you're running a backported kernel