Contribution Checklist for Committers
Contents
1. Verify Patch Conformance
Verify the contributor's copyright status: The patch should have either a Signed-off-by or the contributor should have a copyright assignment with the FSF
- Does the user's patch resolve (fully or partially) a Bugzilla entry? If so then make sure that the [BZ #x] appears in the git commit log
2. Gather Consensus For The Change
Don't commit a patch without consensus! Refer to the page on Consensus for the rules on how/when consensus is achieved.
For changes to release branches (backports), see the Release policy documentation.
3. Update The NEWS File
Provide attribution if the bug reporter followed the security process. Please add their name to the NEWS security section:
* We would like to thank the following people for their help with security related issues in this release: * John Dow and Jane Smith (Bug XXXX). ...
If a Bugzilla entry has been resolved by the patch, and this is a backport to a release branch, make sure to update the NEWS file with the Bugzilla number (and bug summary, for 2.23 and later branches). For mainline fixes, the list of fixed bugs will be inserted by the release manager just before release.
Resolved bugzilla numbers should be added to the NEWS in numerical order (not in the order of resolution).
4. Set Your Committer Information
Make sure you've setup your desired username and email address with git config as described in the GlibcGit page under the Git Settings section. This will be used as the committer tag on the actual commit.
To display the current user settings use the following command: git config -l
5. Provide Attribution to Patch Author When Committing
When committing a patch for another author make sure to attribute the author on the commit, as described on the GlibcGit page under the Author Attribution section.
6. Create a Proper Commit Message
The user submitted patch should have included a git commit message. Use that, along with any addition you need to do for Reviewed-by.
7. Preparing To Git Push
As commit volumes increase there is the likelihood that conflicts will emerge between the time that a working branch was checked out and when a commit is pushed upstream. Pushing a commit when this happens will result in non-descriptive merge commits which pollute the git log.
To limit the number of automatic merges that take the place the committer should do the following:
- Rebase the tree before pushing in order to avoid a merge commit.
git remote update git stash git pull --rebase git stash apply
You may have to manually resolve conflicts and git add stashed files.
- Do a compile test after the rebase to verify that the fix still builds.
Do a fast make check (make fast-check=yes check) if you're paranoid.
If you had stashed files then you need to perform a git commit.
- Do a git push dry-run
git push --dry-run ssh://<username>@sourceware.org/git/glibc.git <local_branch>:refs/heads/master To `ssh://<username>@sourceware.org/git/glibc.git` 8e47560..1cac723 <local_branch> -> master - Verify that only the intended commits are in the range:
git log 8e47560..1cac723
- Do the git push upstream
git push ssh://<username>@sourceware.org/git/glibc.git <local_branch>:refs/heads/master
8. Update Bugzilla
If the commit message included the bug number it will be automatically mentioned in the bug by the auto-annotation hook for git pushes, but you must still close the bug as fixed. You must also set the milestone for the fixed bug to the first mainline release with the fix, so that it is picked up for the list of bugs fixed in that release.
If the commit message does not include the bug number, please make sure to close the bugzilla issue associated with the branch that received the fix and provide a reference to the relevant commit or commits that fix the issue.
e.g.
commit 412bd96612ff5422befb98e990b66d10c26a4b21
Author: Andreas Schwab <schwab@linux-m68k.org>
Date: Tue May 1 01:10:20 2012 +0200
Fix missing nearbyintl@GLIBC_2.1 on powerpc
Resolves #14040.