Contribution Checklist for Committers
1. Verify Patch Conformance
Verify the conformance of the contributor's ChangeLog.
Does the user's patch resolve (fully or partially) a Bugzilla entry? If so then make sure that the [BZ #x] appears in the ChangleLog.
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 ChangeLog File
Merge the author's ChangeLog fragment to the corresponding ChangeLog file.
The date in the ChangeLog entry, once merged, should reflect today's date, the day that you applied the fix.
"As for the date, that should be the date you applied the change."
If the previous ChangeLog entry was from the same author then merge the current entry into the last entry and avoid the additional header.
"When you're adding a new log entry and the header line (the one with the date and your name) would be identical to the existing top header line in the file, then don't add a new header line."
4. Update The NEWS File
If a Bugzilla entry has been resolved by the patch make sure to update the NEWS file with the Bugzilla number.
Resolved bugzilla numbers should be added to the NEWS in numerical order (not in the order of resolution).
Note: The following vim command will auto reformat the list:
:set ai tw=75 <add the resolved bugzilla number in the right order and return to command/input mode> gqap
5. 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
6. 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.
7. Create a Proper Commit Message
The first line of a commit message is a short description of the commit, the next line is a blank line, and the rest of the commit message is the detailed description / rationale for the patch, typically the contents of the patch write-up sent to libc-alpha (but likely minus e.g. descriptions of how that patch differs from previous revisions, or anything else that's only relevant in the mailing list context and not in the revision history).
If you are fixing a bug that contains an open bugzilla bug, please make sure to list the bug # in the commit message such that the auto-annotation features will copy the commit to the bug report.
For more information see: GlibcGit page under the ''Commit Message'' section.
8. 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 ChangeLog conflicts and git add the 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
9. 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.
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.
commit 412bd96612ff5422befb98e990b66d10c26a4b21 Author: Andreas Schwab <email@example.com> Date: Tue May 1 01:10:20 2012 +0200 Fix missing nearbyintl@GLIBC_2.1 on powerpc ChangeLog: 2012-05-01 Andreas Schwab <firstname.lastname@example.org> [BZ #14040] * sysdeps/powerpc/powerpc32/fpu/s_nearbyint.S (nearbyintl): Define in version GLIBC_2.1, not GLIBC_2.0. * sysdeps/powerpc/powerpc64/fpu/s_nearbyint.S (nearbyintl): Likewise.