For the Lucid development cycle we want to review our policy for accepting updates to the previously released kernel. This is even more important as Lucid will be the next LTS and we want to spend as much focus and time on the Lucid development as we can.


With the upcoming LTS in mind we want to look at our SRU policy and adopt it to give users the fixes to bug (without causing regression) and at the same time minimize the effort spent on working in old kernel code.

Proposed Policy

Any stable release update must come in form of a patch which has a Launchpad bug report associated. All patches are subject to review on the kernel-team mailing list and require at least two ACKs by senior members of the kernel-team. New kernel packages will be uploaded to a staging PPA first, then to proposed and after a retention period of at least 7 days with no regressions observed they will get moved to updates.

Additionally to the generic requirements acceptable bugs fall into one of the following criteria:

  1. It fixes a critical issue (data-loss, OOPs, crashes) or is security related (security related issues might be covered by security releases which are special in handling and publication).
  2. Simple, obvious and short fixes or hardware enablement patches as long as the next release has not reached beta status. If there is a related upstream stable tree open (see below) this class of patches is required to come through the upstream process. Patches sent upstream for that reason must include their BugLink reference.

  3. For 3 months after a non-LTS release or the lifetime of a LTS release we will be pulling upstream stable updates from the corresponding series. There will be one tracking bug report for each stable update but additional references to existing bugs will be added to the contained patches (on best can do base). Uploads containing a upstream stable patchset increase the retention period to two weeks.
  4. Fixes to drivers which are not upstream are accepted directly if they fall into the first two categories.
  5. $DEITY intervention. Might happen, but very very rarely and will not be explainable.

Unresolved issues

  • RESOLVED: Need to setup a proper staging PPA. At the moment a team-members PPA is used, which is not optimal.
  • RESOLVED: Make sure the staging area gets good test coverage. Kernel-team members should be required to run their machines with that included.
    • working with QA to ensure automated testing of -proposed kernels
  • RESOLVED: Discuss with SRU team about the proposed policy.
  • How do we fit in the ARM kernels (which are currently the same in Karmic and Lucid) topic branches? Do the rebased trees need to be uploaded at the same time or maybe later?

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarizing what was discussed and note any options that were rejected.


The proposed policy modifications were accepted and will be published in the Kernel SRU definition and announced to ubuntu-devel. QA will also be engaged at -proposed to inprove confidence in updates.


specs/KernelLucidSruPolicyReview (last edited 2009-12-01 18:51:06 by apw)