Describe BradFigg/StableKernelPrep here.

How to prepare the git repo master branch for a kernel release

Description

This wiki page describes how to prepare the master branch of a git repository before releasing a new version of an Ubuntu kernel. The intended audience is Ubuntu Kernel Core Developers performing this task, or others interested in the process.

Repository Branch Structure

First, a word about the kernel branches -

master

master branch is the branch that should reflect exactly the release history of the package. The master branch should not be force pushed or rebased except to fix mistakes, and then only very rarely and carefully and after consultation with another kernel stable coredev

master-next

The master-next branch is where patches accumulate to be applied to the next release of the package. The master-next branch is force pushed from the master branch after a new package is created, so that all new patches accumulate on top of what is released.

Preparing a release

1. Check out a clean copy of the master branch

    git checkout master
    git fetch
    git clean -dxf
    git reset --hard origin/master

2. Check out a copy of the master-next branch for the same Ubuntu repository.

    git branch --track master-next origin/master-next

3. Examine the master-next branch and verify that:
   1. A 'start new release' commit imediately follows the closing commit of the previous release.
   2. There is a 'Bump ABI' commit if one of the commits on the master-next branch requires it.
   3. You want all of the commits on the master-next banch which follow the last release.

    git log --pretty=oneline master-next

4. Pull all the commits from the master-next branch over to the master branch.

    git co master
    git rebase master-next

5. Update the changelog to include all the added commits by running:

    fakeroot debian/rules insertchanges

6. Add the tracking bug using the tools from kteam tools:

    create-release-tracker

   Warning: This will create a (visible) release tracking bug; use with care.

7. Review the changelog and make sure it looks correct
   

8. Edit debian.master/changelog
   

   • replace UNRELEASED with series-proposed

   • update the packagers line with your name and email address and the current time
     

9. Commit that changelog with

    git add debian.master/changelog
    git commit -s -m "UBUNTU: Ubuntu-<version>"
    git tag -s -m Ubuntu-<version> Ubuntu-<version>

   where <version> is copy and paste from head debian.master/changelog

10. Run the verify-release-ready script to make sure everything is OK
    

    • If it's not then you can fix it and force commit or force tag your local tree, making sure it's right before you push to the master repo
      

11. Test build it and do a quick test boot if you can (I typically only build binary-generic)
    

12. Push your git branch to the origin master branch, explicitly including the tag

     git push origin master <tagname>

13. Update the master-next branch.

     git co master-next
     git reset --hard master
     git push origin +master-next