Describe BradFigg/StableKernelPrep here.
How to prepare the git repo master branch for a kernel release
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 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
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
- Check out a clean copy of the master branch
git checkout master git fetch git clean -dxf git reset --hard origin/master
- Check out a copy of the master-next branch for the same Ubuntu repository.
git branch --track master-next origin/master-next
- Examine the master-next branch and verify that:
- A 'start new release' commit imediately follows the closing commit of the previous release.
- There is a 'Bump ABI' commit if one of the commits on the master-next branch requires it.
- You want all of the commits on the master-next banch which follow the last release.
git log --pretty=oneline master-next
- Pull all the commits from the master-next branch over to the master branch.
git co master git rebase master-next
- Update the changelog to include all the added commits by running:
fakeroot debian/rules insertchanges
- Add the tracking bug using the tools from kteam tools:
Warning: This will create a (visible) release tracking bug; use with care.
Review the changelog and make sure it looks correct
- replace UNRELEASED with series-proposed
update the packagers line with your name and email address and the current time
- 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
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
Test build it and do a quick test boot if you can (I typically only build binary-generic)
- Push your git branch to the origin master branch, explicitly including the tag
git push origin master <tagname>
- Update the master-next branch.
git co master-next git reset --hard master git push origin +master-next