OpeningRelease

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.

linux

  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 git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git 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. reconcile-generic is available in the kteam-tools git repo (git://kernel.ubuntu.com/ubuntu/kteam-tools.git), look at devel/reconcile-generic. 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 v2.6.32 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-1.0 which needs to have a commit message "UBUNTU: Ubuntu-2.6.NN-1.0".
    • Don't forget to tag the commit Ubuntu-2.6.NN-1.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
mv .git/* .
rmdir .git
vim config
  change bare = true
As a final step, make sure everything is owned by the "kernel_cdev" group.

  13. Once the tree is opened on kernel.ubuntu.com, you should now be able to push all the changes to it (See Kernel/Dev/MaintainingRelease). Just make sure you set the remote "origin" correctly.

  14. After the tree is officially opened on kernel.ubuntu.com, be sure to update the debian.master/control.stub.in file and update the "Vcs-Git:" line to point to the newly opened repo. 
    vi debian.master/control.stub.in
Vcs-Git: http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-<RELEASE>.git

linux-meta

You can wait to prepare the linux-meta tree until the first official upload to the archive is going to be done. We'll again use Maverick in this example.

  1. Create linux-maverick-meta (ie clone ubuntu-lucid-meta). 
    git clone ubuntu-lucid-meta ubuntu-lucid-meta ubuntu-maverick-meta
  2. Add a new changelog entry to start the new release 
    cd ubuntu-maverick-meta
vi meta-source/debian/changelog
:call NewVersion()
:call Finalise()
Edit the version and change "UNRELEASED" to the release pocket name
Add a changelog note similar to "* Initial Maverick ABI"
:wq!
  3. Update RELEASE_NAME 
    vi meta-source/debian/rules
udpate RELEASE_NAME to the new release
:wq!
git add meta-source/debian/rules
git commit -s -m "UBUNTU: Update RELEASE_NAME from <PREV_RELEASE> to <NEW_RELEASE>"
  4. Temporarily disable lbm (linux-backports-modules) as this package won't exist until later in the development cycle. Don't forget to revert this later in the development cycle when lbm comes into existence. 
    for file in meta-source/debian/control.d/*
    comment out the lbm sections
git add meta-source/debian/control.d/
git commit -s -m "UBUNTU: Temporarily disable lbm"
  5. Edit the changelog to include a note about the updated RELEASE_NAME and disabling lbm: 
    vi meta-source/debian/changelog
 * Update RELEASE_NAME from <PREV_RELEASE> to <NEW_RELEASE>
 * Temporarily disable lbm
:wq!
git add meta-source/debian/changelog
git commit -s -m "UBUNTU: Ubuntu-<META-PKG-VERSION>"
git tag -s -m Ubuntu-<META-PKG-VERSION> Ubuntu-<META-PKG-VERSION>
  6. Officially open it the tree on kernel.ubuntu.com/git 
    cd kernel.ubuntu.com:/srv/kernel.ubuntu.com/git/ubuntu/
mkdir ubuntu-<RELEASE>-meta.git
cd ubuntu-<RELEASE>-meta.git
git init
mv .git/* .
rmdir .git
vim config
  change bare = true
As a final step, make sure everything is owned by the "kernel_cdev" group.

  7. Once the tree is opened on kernel.ubuntu.com, you should now be able to push the changes to it (See Kernel/Dev/MaintainingRelease). Just make sure you set the remote "origin" correctly.

  8. After the tree is officially opened on kernel.ubuntu.com, be sure to update the meta-source/debian/control.common file and update the "Vcs-Git:" line to point to the newly opened repo. 
    vi meta-source/debian/control.common
Vcs-Git: http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-<RELEASE>.git

Kernel/Handbook/ReleaseManagement

Kernel/Handbook/ReleaseManagement/OpeningRelease (last edited 2012-05-16 13:27:45 by leannogasawara)