KernelMaverickNewKernelOnLTS

Differences between revisions 1 and 2
Revision 1 as of 2010-04-28 08:30:38
Size: 2622
Editor: eth0
Comment:
Revision 2 as of 2010-05-07 18:26:04
Size: 6831
Editor: 79-70-103-73
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''': AndyWhitcroft, TimGardner  * '''Contributors''':
Line 10: Line 10:
This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. 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.
Line 14: Line 34:
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) No release note would be meaningful for Maverick, no user visible changes
would be present in Maverick for this feature.
Line 16: Line 37:
It is mandatory.
Line 20: Line 40:
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. 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.
Line 22: Line 45:
== User stories == 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.
Line 26: Line 65:
== Design == 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.
Line 28: Line 73:
You can have subsections that better describe specific parts of the issue.
Line 32: Line 76:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: 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.
Line 34: Line 84:
=== UI Changes ===
Line 36: Line 85:
Should cover changes required to the UI, or specific UI that is required to implement this === Maverick Kernels for Lucid ===
Line 38: Line 87:
=== Code Changes === 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.
Line 40: Line 93:
Code changes should include an overview of what needs to change, and in some cases even the specific details.

=== Migration ===

Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.
Line 51: Line 96:
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. 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.
Line 53: Line 100:
This need not be added or completed until the specification is nearing beta.

== Unresolved issues ==

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
Line 61: Line 103:
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.  * 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
 * Issues
   * 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

== Summary of Discussion ==

== Final Resolution ==

Summary

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.

Rationale

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.

Assumptions

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.

Implementation

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

  • 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
  • Issues
    • 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

Summary of Discussion

Final Resolution


CategorySpec

KernelTeam/Specs/KernelMaverickNewKernelOnLTS (last edited 2010-05-17 12:19:18 by 79-70-103-73)