Ubuntu Wiki

Each release cycle a member of the Ubuntu kernel team assumes the role of Ubuntu Kernel Release Manager. One of the first responsibilities for this individual is to open and prepare the git tree for that release. The following information documents the steps for starting this new git tree. We'll use Maverick as the new tree example.

Note: In the following example we use 'M' to represent Maverick. At the time the tree was opened, we did not know the official name of the next release other than the letter it would start with, hence M.

1. TAG the lucid tree, "Ubuntu-M-base" and "Ubuntu-M-sync". These are your tags. No one else should touch them on pain of death. Ubuntu-M-base represents the original point where you forked M from Lucid. This tag will never move. As no one will consider Ubuntu-M for patching until M officially opens in the archive, Ubuntu-M-sync will then allow you to keep track of the patches applied to Lucid after M's been forked. Ubuntu-M-sync will move each time you sync with the latest patches applied to Lucid.

   cd ubuntu-lucid (make sure you're at the latest tip)
   git tag -s -m "Ubuntu-M-base" "Ubuntu-M-base"
   git tag -s -m "Ubuntu-M-sync" "Ubuntu-M-sync"

2. Create M (ie clone ubuntu-lucid).

   git clone --reference ubuntu-lucid ubuntu-lucid ubuntu-m

3. The next few steps is just splitting, squashing, and dropping commits ie. comparing Ubuntu-M-base with the latest master should diff identical. We leverage a script called reconcile-generic to help with this task. It's a good idea to save the output of reconcile-generic to help generate the Ubuntu delta blueprint later on.

   cd ubuntu-m
   reconcile-generic Ubuntu-M-base v2.6.33 > /tmp/RESULT

   Example RESULT output can be viewed at http://people.canonical.com/~ogasawara/RESULT

4. Examine /tmp/RESULT and look for any commits which touch debian and not debian (marked 'needs debian split out'). Split these into two commits.

   for example:
   
   1cd09b44bbb7cb6a5521d83234e65f72193a1c3d (pre-stable) drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
     NEEDED (needs debian split out)
   
   cd ubuntu-m
   git rebase -i 1cd09b44bbb7cb6a5521d83234e65f72193a1c3d~1
   # s/pick/edit/ for 1cd09b44bbb7cb6a5521d83234e65f72193a1c3d
   git reset HEAD^
   git add <not-debian-file(s)>
   git commit
   git add <debian-file(s)>
   git commit
   git rebase --continue
   
   It's a good idea to make sure nothing has changed code wise within the tree after doing this.  A `git diff Ubuntu-M-base master` should show no changes.

5. move all debian commits to the top and squash them. If you had to split out debian commits in the previous step, you'll likely want to re-run reconcile-generic to make sure you have all the DEBIAN commits including the latest ones that were split out.

   reconcile-generic master v2.6.33 > /tmp/RESULT2

6. drop all added and then reverted commits (marked REVERT or REVERTED),
7. Insert and commit a fake changelog entry for 2.6.NN-0.0 which needs to have a commit message "UBUNTU: Ubuntu-2.6.NN-0.0".
   • Don't forget to tag the commit Ubuntu-2.6.NN-0.0
8. Then startnewrelease like normal, ie 2.6.NN-1.1 and so on. Obviously we don't care about the ABI until we formally put the kernel into the archive so for now we can just stay on -1.1, -1.2, -1.3 ... for the time being.
   • Note, you can skip the ABI and module checks by echo'ing 1 to an 'ignore' and 'ignore.modules' file for each arch within the abi directory. There does exist an abi-disable script to do this.

     for each arch
         echo 1 >"debian.master/abi/$arch/ignore"
         echo 1 >"debian.master/abi/$arch/ignore.modules"

9. rebase to 2.6.33 dropping any upstream commits at the same time (marked IN:)

   git rebase -i v2.6.33

   Remember to tag everything so we can look back if we need to.
10. After the rebase, don't forget to update the configs. It's highly recommended to also use the config2options script to make updating the configs less painful.

    fdr updateconfigs
    fdr updateportsconfigs

11. Until this new tree is official, we have to keep in sync with Lucid if any new patches are applied to Lucid that are not already in the new tree. The easiest way to do this is to just cherry pick the patches from Lucid into the new tree.
12. When the tree is ready, officially open it on kernel.ubuntu.com/git

    cd kernel.ubuntu.com:/srv/kernel.ubuntu.com/git/ubuntu/
    mkdir ubuntu-<RELEASE>.git
    cd ubuntu-<RELEASE>.git
    git init
    cd .git
    mv * ../
    cd ..
    vim config
      change bare = true

Kernel/Handbook/Developer