civilinfrastructureplatform:cipkernelmaintenance
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
civilinfrastructureplatform:cipkernelmaintenance [2017/12/13 18:04] bwhct [Releases] Current release cadence is about once a month |
civilinfrastructureplatform:cipkernelmaintenance [2017/12/13 18:24] bwhct [Read the code] Fix formatting of code |
||
|---|---|---|---|
| Line 85: | Line 85: | ||
| If you are doing this after a stable release, all the patches will be in the git history of the branch. | If you are doing this after a stable release, all the patches will be in the git history of the branch. | ||
| - | If you want to do this during the review period before release, you should be able to receive the patches through the [stable@vger.kernel.org](http://vger.kernel.org/vger-lists.html#stable) list. This is a high-traffic list, so you may want to filter by subject. However, at the time of writing, Greg's script that sends patches out for review has a bug that causes patches with non-ASCII characters to be dropped. Greg and most other stable maintainers also publish pending patches in a git repository, either as a quilt patch | + | If you want to do this during the review period before release, you should be able to receive the patches through the [[http://vger.kernel.org/vger-lists.html#stable|stable@vger.kernel.org]] list. This is a high-traffic list, so you may want to filter by subject. However, at the time of writing, Greg's script that sends patches out for review has a bug that causes patches with non-ASCII characters to be dropped. Greg and most other stable maintainers also publish pending patches in a git repository, either as a quilt patch |
| series or as a rebased git branch. | series or as a rebased git branch. | ||
| Line 105: | Line 105: | ||
| * If the author is Linus, be aware that he often makes security fixes without describing the security implications. | * If the author is Linus, be aware that he often makes security fixes without describing the security implications. | ||
| - | Look for a //Fixes:// tag in the commit message, identifying which commit introduced (or only partly fixed) the bug that's being fixed: | + | Look for a ''Fixes:'' tag in the commit message, identifying which commit introduced (or only partly fixed) the bug that's being fixed: |
| * If it's not present, look to see if the free-form text identifies which commit introduced it. | * If it's not present, look to see if the free-form text identifies which commit introduced it. | ||
| * Is that commit actually present in the stable branch? Don't forget that it might have been backported as part of another stable update. If not, this probably doesn't belong in the stable branch. | * Is that commit actually present in the stable branch? Don't forget that it might have been backported as part of another stable update. If not, this probably doesn't belong in the stable branch. | ||
| - | * Find the first release containing a commit: <code> git describe --contains --match 'v*' *hash* </code> | + | * Find the first release containing a commit: |
| - | * Check whether a stable branch contains a backported commit: <code> git log --pretty=oneline --grep=`*hash* `v`*version*`..stable/linux-`*version*`.y </code> | + | |
| - | The //git-check-in-stable// script from [[https://anonscm.debian.org/cgit/kernel/kernel-team.git/|kernel-team.git]] provides a shortcut (and slightly nicer output format) for the second command. | + | > ''%%git describe --contains --match 'v*' %%**//hash//**'' |
| + | |||
| + | * Check whether a stable branch contains a backported commit: | ||
| + | |||
| + | > ''%%git log --pretty=oneline --grep=%%**//hash//**%% v%%**//version//**..stable/linux-**//version//**.y'' | ||
| + | |||
| + | The ''git-check-in-stable'' script from [[https://anonscm.debian.org/cgit/kernel/kernel-team.git/|Debian kernel/kernel-team.git]] provides a shortcut (and slightly nicer output format) for the second command. | ||
| ==== Read the code ==== | ==== Read the code ==== | ||
| Line 120: | Line 125: | ||
| * Ignore white-space changes - they shouldn't be combined with fixes, but at least they won't do any harm). | * Ignore white-space changes - they shouldn't be combined with fixes, but at least they won't do any harm). | ||
| * If a file contains multiple similar blocks of code, is the right one being patched? | * If a file contains multiple similar blocks of code, is the right one being patched? | ||
| - | * If the patch changes a function to acquire and then release a lock or other resource, are there any additional paths through the function where the resource can leak? For example, there might be an extra //return// statement in the stable branch, compared to the upstream version. | + | * If the patch changes a function to acquire and then release a lock or other resource, are there any additional paths through the function where the resource can leak? For example, there might be an extra ''return'' statement in the stable branch, compared to the upstream version. |
| - | * If the patch adds a //return//, //goto//, or //break// statement, again check for leaks. | + | * If the patch adds a ''return'', ''goto'', or ''break'' statement, again check for leaks. |
| * Sometimes the upstream commit will have been modified (backported) to create the stable patch, because it depended on new or changed APIs, or because a function that needed to be fixed has been merged or split up in some way. If it has been backported, do the modifications make sense? If someone other than the original author backported it, they should have added an explanation in the new commit message. | * Sometimes the upstream commit will have been modified (backported) to create the stable patch, because it depended on new or changed APIs, or because a function that needed to be fixed has been merged or split up in some way. If it has been backported, do the modifications make sense? If someone other than the original author backported it, they should have added an explanation in the new commit message. | ||
| * If the patch changes the type or semantics of a function, all its callers probably need to be updated. In the stable branch, there might be additional callers compared to upstream. Have any of them been missed? | * If the patch changes the type or semantics of a function, all its callers probably need to be updated. In the stable branch, there might be additional callers compared to upstream. Have any of them been missed? | ||
civilinfrastructureplatform/cipkernelmaintenance.txt · Last modified: 2023/09/28 06:49 by jki-siemens
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
