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

  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 conflicts and git add 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>@sourceware.org/git/glibc.git <local_branch>:refs/heads/master
    To `ssh://<username>@sourceware.org/git/glibc.git`
               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>@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.

None: Committer checklist (last edited 2021-08-11 02:44:07 by SiddheshPoyarekar)