Contribution Checklist for Committers

1. Verify Patch Conformance

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.

If the previous ChangeLog entry was from the same author then merge the current entry into the last entry and avoid the additional header.

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>

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:

  1. Rebase the tree before pushing in order to avoid a merge commit.
    git remote update
    git stash
    git pull --rebase
    git stash apply
  2. You may have to manually resolve ChangeLog conflicts and git add the stashed files.

  3. Do a compile test after the rebase to verify that the fix still builds.
  4. Do a fast make check (make fast-check=yes check) if you're paranoid.

  5. If you had stashed files then you need to perform a git commit.

  6. Do a git push dry-run
    git push --dry-run ssh://<username> <local_branch>:refs/heads/master
    To `ssh://<username>`
               8e47560..1cac723  <local_branch> -> master
  7. Verify that only the intended commits are in the range:
    git log 8e47560..1cac723
  8. Do the git push upstream
    git push ssh://<username> <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 <>
Date:   Tue May 1 01:10:20 2012 +0200

    Fix missing nearbyintl@GLIBC_2.1 on powerpc


2012-05-01  Andreas Schwab  <>

        [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):

None: Committer checklist (last edited 2015-06-04 16:46:14 by CarlosODonell)