Revision 1 as of 2010-01-27 12:30:57
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|This wiki describes the Ubuntu Kernel Stable Release Updates Maintenance Procedure.||This wiki describes the Ubuntu Kernel Stable Release Updates Maintenance Procedure with an example|
This wiki describes the Ubuntu Kernel Stable Release Updates Maintenance Procedure with an example
The following steps in brief shall help in SRU maintenance:
Say you are releasing a stable update for 220.127.116.11
1. Get the source of the upstream stable releases
- git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/2.6.31
2. See what has changed since the last release. Since, in this document we talk about the 18.104.22.168 ubuntu SRU kernel we do the following:
- git log 22.214.171.124..126.96.36.199
- 188.8.131.52 and 184.108.40.206 are tags applied to the git tree. We are trying to find the git log between these tags.
- git log --reverse --pretty=%s v220.127.116.11..v18.104.22.168 will give you a short listing of the patches with the subject lines only and the first subject line will be the one which was applied immediately after the tag 22.214.171.124 was applied.
- git log --reverse --pretty=oneline v126.96.36.199..v188.8.131.52 will you give you the subject line and the commit id. In the next step, you can use this commit id for the last patch which will be application of the tag 184.108.40.206
3. Now that you have a listing of the patches, you need to get the actual patches. This can be done by: find out the commit id for the patch that applies 220.127.116.11 by doing a git log and searching for 18.104.22.168. copy the commit id for this patch. We shall need it now to generate the patch set. Commit id for the tag 22.214.171.124 can be found from the step above
git format-patch <commit-id-for-tag-126.96.36.199> .. <commit-id-of-tag-188.8.131.52> -o ./patches/
- You can of course use any convenient location to store your patches generated. These patches will be numbered as 0001* and so on.
4. Now start looking at the patch from 0001* .. look at the code and review it. You could use the following as a guideline for your review:
- why is the patch applied ? b. could you categorize it as follows: (please change/add any other category you feel more appropriate)
- Some tips for beginners:
- Look in kernel bugzilla for bugs which are mentioned in the patch description. Read the comments by other kernel developers to get more insight in the development of a patch. If the patch is a regression, look at the previous patch which introduced the regression. look at user comments.
- II. Sometimes when you are reviewing the patchset in 184.108.40.206, the review of 220.127.116.11 may be over upstream. Look out for this. Look if any regression was introduced in 18.104.22.168 an is fixed in the forward releases. If so, withhold this patch and apply it along with the fix. Comment this in your review mail.
III. Look at launchpad for bugs which this patch might fix. Note this bug number and its link. Note that you could look at launchpad bugs with their associated upstream bug number too. Look at this: https://bugs.edge.launchpad.net/bugs/bugtrackers/linux-kernel-bugs and sort it on the upstream bug number. Then you could see if the upstream bug number is linked against a launchpad bug.
- Now that your personal review of the stable release patches is over, you need to send it across to other people on the ubuntu kernel list, so that they can review it and ack it or give further insight. Before doing this do the following:
5. Open a bug on Launchpad indicating that 22.214.171.124 (in our eg) has been released upstream and you will like to see these updates in ubuntu release-name( karmic in our eg). Look at an example tracking bug. I looked at the one Leann made. Here is a link: https://bugs.edge.launchpad.net/ubuntu/karmic/+source/linux/+bug/496816
- Make a similar bug that tracks the updates. This bug is called the "tracking bug" for an update. You should also mention what launchpad bug this update fixes. Also if you are reverting any patch in favour of an upstream patch, then mention this in the tracking bug on launchpad. However this you will find out only when you apply the patches. The patches can be applied only after the next step. So you could update this part later.
6. Now you need to include this bug link in all your patches. This indicates, that you are applying this patch to the ubuntu kernel for resolving this launchpad bug. This can be done by using the maintools written by Stefan. git://kernel.ubuntu.com/smb/maint-tools.git
- You configure the maint-tools by looking at the maint-tools/doc/example-maintscript.cfg. Change the signer: field in this and mark your name there and make an alias with your name. Then put this modified maintscript.cfg in your ~/.maintscript.cfg Now execute the following:
1) cd <dir-where-you-have-your-patches>
2) tool-dir= <location-where-you-have-your-git-mainttools> 3) export tool-dir
4) $tool-dir/maint-modify-patch -b <bugnumber> *.patch
- 5) $tool-dir/maint-modify-patch -s *.patch
7. Besides the buglink above, you also should add the link to any bug on launchpad that the patch resolves in particular. Use the maintools to do so.
8. You now need to sign these patches with your name. This is done using the maintools and is already described above.
9. Now you are ready to apply these patches. So create a new branch on which you will apply these patches.
- git checkout master git pull git checkout -b stable-126.96.36.199
git am <location where your patches are>/00*.patch
- would apply all the patches that you created using git format. f the above command fails, then most probably the reason is that you already had a similar patch in your ubuntu tree before. Do the following in this case. Identify why the patch is already present in your ubuntu tree. was it because of security or was it a [sauce] patch that enable hardware or one which was accepted upstream but not yet released as a part of stable updates ? Unless its a security patch, revert the existing patch in favour of the upstream patch. The idea is that you want the most updated patch in such a
case and the upstream patch is most likely to be that one. The security patch is however not reverted. You keep the security patch and skip the upstream patch. However you need to mention this in your review email. So, then reset the head of the tree to where it was before applying your patches:
git reset --hard <commit-id> now do the revert:
- When you revert a patch in favour of an upstream patch note this in the git message for revert -
git revert -e -s <commit-id-that-you-want-to-revert> "this patch is reverted in favour of an upstream patch with commit id released in a stable update 2.6.31.<y> now again apply the patches in the stable tree:
git am <location where your patches are>/00*.patch
10. Now compile the branch with all these patches applied. See if any patch needs to bump the ABI. Rever that patch, see if the kernel compiles. If so, then you have identified which patch needs to bump the abi. Note this patch. Mention this in your review email. The ABI bump can be done as follows:
- fakeroot debian/rules insertchanges
- vim debian.master/changelog - increment the abi by 1. eg 2.6.31-18.56 would be 2.6.31-19.56
- touch debian.master/rules.d/control.stub.in
- fakeroot debian/rules clean
- git add debian.master
- git commit -s -F debian/commit-templates/bumpabi
11. Now that your patches are applied, you need to push them on zinc.
Now write an email to email@example.com indicating the tracking bug number and the sru update number for your ubuntu kernel and release so and so. Indicate what bugs on launchpad this update might fix. Also indicate the location to the public repository where your tree is kept. Also indicate the location of the upstream changelog and patchset for this
stable update. This shall generally be:
http://kernel.org/pub/linux/kernel/v2.6/patch-2.6.<x>.<y>.bz2 and then append the review of those patches. The review message should be as follows: output of: git log --pretty=short v188.8.131.52..v184.108.40.206 after every patch description (from the above command), should be the following:
Category: One line description of what the patch does. Whether any patch was reverted for applying this patch. Whether this patch causes regression, the fix of which is released in a forward stable release, due to which we shall apply the patch with that fix. Whether this patch is an ABI bumper.
Thats it !.. press the send button ! and you are good to go