Rolling Kernel Maintenance

Registered by Leann Ogasawara

The purpose of this session is to discuss how the kernel team would handle a rolling kernel release should Ubuntu move to a rolling release model between LTS releases.

Blueprint information

Not started
Leann Ogasawara
Leann Ogasawara
Needs approval
Canonical Kernel Distro Team
Series goal:
Milestone target:
milestone icon ubuntu-13.04-month-5

Related branches



== Session Summary ==
1. Report on any pertinent outcomes from the HWE stack discussions
    1a. See . The biggest impact for the rolling release in terms of the HWE stack is the agreement to bake the kernel that will be delivered in an LTS point release HWE stack in the rolling release for a period of time (eg 3mo) before introducing it into the LTS release.

2. Until an official decision is made regarding a rolling release, the ubuntu-raring git repo master branch will remain on v3.8.x.

3. An unstable-3.9 branch has been open to track the current v3.9 development.

4. In a rolling release model, do we still work out of a master/master-next branch or do we need additional branches or even trees set up?
    4a. We will keep a master and master-next branches. The master/master-next branches will only follow a stable release, ie never on an -rc, only 3.x.y
    4b. We will also have an unstable-3.x branch tracking the current upstream kernel under development. This branch will ride the latest -rc’s and eventually a stable release up until a 3.x.2 upstream stable release.

5. When will a new version be pushed to master, eg v3.8->v3.9. Do we wait until eg v3.9.2 (ie bake 2 stable updates)
    5a. Once the unstable-3.x branch hits a 3.x.2 upstream stable release, the unstable-3.x branch will be pulled into master/master-next for continued support and maintenance.

6. For the master/master-next branches, do we rebase to the latest upstream stable releases, or do we apply patches individually?
    6a. The initial pull from unstable-3.x will essentially have to be a rebase. However, after that we will follow the normal stable maintenance team’s model for individually picking up patches rather than rebasing.

7. What will be uploaded to the archive?
    7a. We will only officially upload what is sitting on the master branch. master-next will continue to queue patches intended for master.
    7b. unstable-3.x will be uploaded to a PPA for early adoption and testing

8. Who on the kernel team owns which of the branches/treees?
    8a. master and master-next is owned by the kernel stable maintenance team
    8b. unstable-3.x is owned by the kernel development team

9. How will we handle security updates for the monthly updates/releases?
    9a. We suspect only critical security updates and bug fixes would warrant an update to the previous month’s release. All other updates/fixes will target the upcoming monthly release.

10. How and when should we handle config reviews? Should we announce the results like we normally do for a 6mo release?
    10a. We will perform config reviews upon the opening of a new unstable-3.x branch. We are announce any interesting results to the kernel team and ubuntu-devel mailing lists

11. How should we approach the QA'ing of the kernels in the rolling release?
    11a. QA would likely be a consumer of the unstable-3.x kernel uploaded to the PPA for early adoption and testing. That way we can try and catch any issues early before the kernel officially lands in the archive.

12. Can stable and unstable kernels be offered coinstallable / in parallel?
    12a. That is possible today if you installed from both the archive and the PPA and ensure the older kernel is not reaped via the clean old kernels process. At this time we do not plan on providing both the stable and unstable kernels in the official Ubuntu archive. Only the stable kernel will live in the archive, the unstable kernel will be in the PPA.

13. Are the DKMS packages automatically tested (at least that they don't ftbfs, autopkgtests can do this easily) in jenkins against next kernel(-ppa)?
    13a. DKMS packages are not automatically tested at this time. However, the kernel team does specifically interlock with DKMS package maintainers when a new kernel version is being prepped in order to sort out any DKMS issues.


Work Items

Work items:
[leannogasawara] Dependent on the rolling release proposal being ratified, document the exact policies and procedures outlined above as well as interlock check points with eg. DKMS package maintainers (rolling release proposal Nack'd): POSTPONED