• Launchpad Entry: jaunty-kernel-tree-mgt

• Created: PeteGraner

• Contributors:

• Packages affected:

Summary

Review of how the kernel team currently manages the git tree, looking for process improvements, automation and things in general to make the kernel developer's day to day life easier. This session will focus on the current kernel tree management, documenting how that management is done and also why it is done that way. Later we will focus on possible improvments to process or the existing automation to simplify the process where possible.

Release Note

This is a process rather than release based Blueprint, and therefore there will be no Release Note update associated with this track.

Rationale

The kernel tree managment is poorly documented and has evolved over time into its current state. The purpose here is to both ensure we understand all of the steps involved in maintaining the kernel tree and also the reasons for those steps. We also intend to spend time looking at process and automation with a view to simplifying our processes and improve automation.

Assumptions

We assume that the reader is familiar with linux kernels, the mainline kernel development and release process, aware of the mainline stable release process, and has an understanding of the git tools used to manage the kernel trees.

Background

The kernel is maintained in the community using git. Linus has the master tree containing the combined development trees.

Linus' Tree

The source for the kernel for our releases is Linus' tree. This is the main development branch. New releases are generated by merging the changes from a large number of subsystem maintainer trees. Blessed combinations are released from here, both pre-releases for testing and primary point releases. These releases form the back bone of the early kernels during our alpha phases.

Stable Trees

After release of a particular point release development moves on with new feastures merging to mainline. The stable team then takes ownership of identifying and back porting critical fixes to the now closed releases. These appear in the 2.6.x.y stable trees. These are a significant source of stable updates for our releases.

Ubuntu's Trees

The Ubuntu kernel aims to be as close as possible to the mainline kernel trees. There are two main reasons to differ from the mainline kernel:

1. to handle our Ubuntu packing system (debian/*)
2. to pull down bug fixes and functionality which are not yet available in the mainline kernel

We maintain a set of trees per release, named for the release in the kernel.ubuntu.org git repository, for example the Intrepid trees are in the ubuntu/ubuntu-intrepid.git repository, at the URL below:

• http://kernel.ubuntu.com/git/

Our trees are actually split into two or three parts depending on the release:

1. Linux -- the main tree consisting of the bulk of the kernel,
2. Linux Ubuntu Modules -- representing Ubuntu supported modules, and
3. Linux Backport Modules -- representing useful updated module.

Main Tree

The main kernel tree is located in the ubuntu-<release>.git git repository. This contains the primary source for the kernel, plus all of the debian build support, kernel configurations etc required to build the main kernel image packages.

This is based of a specific upstream linux release such as 2.6.27, any stable updates for that release, and any local Ubuntu modifications (Sauce patches).

Linux Ubuntu Modules

The Linux Ubuntu Modules tree carries any additional modules which are not part of mainline which we are supplying and maintaining. In releases prior to Intrepid this was a separate package located in the ubuntu-<release>-lum.git git repository. From Intrepid these are now carried in our Main kernel tree in the ubuntu/ subdirectory.

Linux Backport Modules

The Linux Backport Modules tree carries updated modules and drivers from the latest mainline, it is located in the ubuntu-<release>-lbm.git git repository. Where newer versions of drivers etc appear upstream and those provide significant advantage for for the user base it is desirable to backport those to the main kernel. In some cases the existing driver is functional for a significant existing user base, in this case updating the driver introduces significant risk to the existing user base. In this case we may add the updated driver to the linux backports module allowing those users to opt-in to the new driver.

Release Milestones

In large part kernel updates and releases are driven by the Release Process. A new release cycle starts as soon as the previous release goes final. Preparation for Jaunty started as soon as the 8.10 release was published.

In the following six months a number of alpha and beta releases are made, there are 6 scheduled alphaN snapshots, a beta snapshot, then a release candidate and the final release. Kernels are prepared for each of these releases, typically by rebasing against the latest mainline. Following the final release the kernel is effectivly closed and may only be updated via the SRU process. For longer term support (LTS) releases scheduled updates will also have kernels prepared, but these will not be rebased.

What we do

Starting a new release cycle

For each new release cycle a likely kernel release is picked. This will be the mainline kernel release which should be available in time for the proposed release date. Typically this kernel will be in pre-release (-rcN) for the early alphas before officially releasing.

We will then pull foward all of our Ubuntu specific changes onto this new mainline baseline. During this we review each patch dropping those which are no longer applicable. Once this is complete the repository is pushed up to kernel.ubuntu.com and an Upload performed.

Generating a new repository

The first step is to generate an initial ubuntu/ubuntu-<release>.git, on the central git server zinc.canonical.com:

• cd /srv/kernel.ubuntu.com/git/ubuntu
  GIT_DIR=ubuntu-jaunty.git git init --shared=group
  cd ubuntu-jaunty.git
  chmod +x hooks/post-update                      # Ensure this repository is accessible over http://
  git config receive.denynonfastforwards false    # Allow forced branch updates initially

NOTE: as we have marked this as a shared=group repository we should not need to set our umask, and so should not need the pre-receive hook.

In order to prevent the first upload being truly enormous we can seed the repository with the majority of Linus' tree from the previous release.

• git fetch ../ubuntu-intrepid.git tag v2.6.27
  git branch -f master v2.6.27

Clone this repository locally

Then we can clone this repository locally, this can be done one of two ways to reduce the size of the initial download. If you have a local clone of Linus' tree which you use as a common object store you can clone using that as a reference:

• git clone --reference linux-linus ssh://zinc.canonical.com/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-jaunty.git

If you prefer to have a fully loaded repository you can still seed that repository as we did on zinc:

• mkdir ubuntu-jaunty
  cd ubuntu-jaunty
  git init
  git fetch ../ubuntu-intrepid tag v2.6.27
  git branch -f master v2.6.27
  git checkout master
  git remote add origin ssh://zinc.canonical.com/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-jaunty.git
  git fetch origin

Initial Release Rebase

First we need to pull in the new base tree from Linus' tree (into our local copy):

• git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  git fetch linus tag v2.6.28-rc6

We also will need the latest and greatest tree from the previous release:

• git fetch --no-tags ../ubuntu-intrepid master:intrepid

We can now review and rebase the changes on the intrepid branch over to the new master branch:

• git reset --hard intrepid
  git rebase -i v2.6.28-rc6
  [lots of hard graft]

XXX: - rebase the existing patches onto the top

• - squash debian updates away, or do we throw them away because this is a new tree
  • - can tell by comparing jaunty to intrepid

Once this is complete we are ready to publish this version of the repository:

• git push origin master

Pre-release Rebases

During the early alpha/beta phase we may well be tracking a pre-release kernel tree and we may well want to rebase again

do we need to rebase at this point or could we just merge in the upstream repeatedly? WHY do we do this?

Patching

Uploading

HOW DO WE DO THIS

Security updates

SRU updates

Point releases

Unresolved issues

Our focus is on improving our implementation of the existing kernel team kernel management process. That process itself should also be reviewed at the same time.

Ideas

1. can we merge our archived kernels, they are one tree really
2. use merge for stable updates
3. backports as smaller packages
4. backports use DKMA as framework?
5. think about handling of an upstream kernel module

BoF agenda and discussion

pgraner's notes

• New release tasks
  • Patch review
    • Need to be sure that when we drop a patch, it's an explicit decision, and coordinated with developers who might be depending on it.
    • next rebase to include a public review of all patches and their fate (e.g. on ubuntu-devel@lists)?
    • Upstreaming of Sauce patches.
• Tree Mgt.
  • Locking the tree past kernel freeze
  • LP bugs needed for check in
  • Why do we rebase?
  • Keep our tree in sync with mainline and branch for releases

CategorySpec