Contribution Checklist

A contribution to the glibc project should always be sent to the appropriate mailing list for the contribution scope:

If you are contributing a new architecture port, see additional information on such contributions.

A high-quality contribution includes the following things:

1. Security

If you believe the bug could be a security issue please follow the security process. If the reporter follows the security process then the project will provide an attribution in the NEWS for the release (see Committer checklist).

2. Bugzilla Entry

A bugzilla entry for a bug should be created and should contain everything a high-quality mailing list submission would contain.

If your contribution fixes a user-visible issue we strongly suggest it should have a bugzilla entry.

If you are contributing a locale related change, please see the Locales page for additional instructions.

Please follow the bugzilla procedures.

3. Contribution Email Subject Line

Your contribution email subject line will become the first line of the commit message for your patch.

A high-quality email subject line for a contribution contains the following tags:

For a Single patch contribution (see below for adding a bug number):

For Multi-part patch set contributions where [PATCH 0/2] is used to described the forth coming patches:

For a request for comments that doesn't have to be a patch at all:

For a request for comments on a patch or patch set:

For a patch that fixes a bug filed in bugzilla (add BZ# suffix):

For a patch that affects a particular architecture only (use the arch as the subsystem):

For a patch that is the Nth version of an earlier patch:

For a patch that is the Nth version of an earlier patch with multiple patches (follows the git send-email format for multiple patches):

For a patch carried on a non-canonical namespace branch, but not necessary in-line in the patch body:

For a patch that is already committed:

4. Properly Identified Contribution Scope

4.1. Base

4.2. Add-Ons (NPTL, localedata, posix, libidn, et al)

4.3. Ports

5. Detailed Explanation of the Patch

The detailed explanation will become the body of the commit message for your patch. Please keep this in mind and format accordingly or indicate to the reviewer which part of the email should be the body of the commit message.

5.1. General Patch Requirements

5.2. Documentation

If your patch adds a new interface then that interface should be documented in the glibc manual.

Where possible please additionally contribute a manual page to the Linux man-pages project:

6. Check For New Warnings

Check the make log for new warnings. Any new warnings generated should have the cause corrected before submission of the patch.

7. Testing

7.1. Testing Locales

Please see the Testing Locales section in the Locales page.

Specific functionality in glibc is often implemented separately for different configurations, such as different operating systems or processor architectures. When identifying and fixing a problem in one of these implementations, the same reasoning might also apply to the others, and the same or a similar fix might also be needed there. You should try to identify these cases, and draw attention to these in your submission (»similar changes to [this] are probably needed [here], too«), or if the case is simple enough try to fix all occurrences at the same time and propose a possibly untested patch, too. Especially for nontrivial issues, it is of course fine to defer to the respective maintainers for help -- we don't expect you to fix SPARC assembler code when you're fixing an issue in an x86 assembler implementation, and neither do we expect you to be able to test a patch for GNU/Hurd when you're fixing an issue in glibc's GNU/Linux-specific code.

Why does the FSF get copyright assignments from contributors?

For GNU C Library Stewards: Template Email for Copyright assignment issues

     Copyright (C) year1, year5 copyright-holder

     Copyright (C) year1, year5, year6 copyright-holder

     Copyright (C) year1, year5-year7 copyright-holder

     Copyright (C) year1-year7 copyright-holder

     Copyright (C) 2012-2013 Free Software Foundation, Inc.
     ... rest of FSF copyright notice ...

     Copyright (C) 2010 other-copyright-holder
     ... rest of other copyright notice ...

11. Attribution

12. Properly Formatted GNU ChangeLog

YYYY-MM-DD<2 spaces>John Doe<2 spaces><>
<tab--->[BZ #<number>]<use this if there is a bugzilla associated with the patch>
<tab--->* login/utmp_file.c (pututline_file): Replace call to 'dup()'<line wrap at or before column 79>
<tab--->with libc internal symbol '__dup()' to avoid access through<line wrap at or before column 79>
<tab--->the PLT.
<tab--->* manual/install.texi: Minimum version updated.
<tab--->* INSTALL: Regenerated.

2008-12-12  John Doe  <>

        [BZ #9999]
        * login/utmp_file.c (pututline_file): Replace call to 'dup()'
        with libc internal symbol '__dup()' to avoid access through
        the PLT.
        * manual/install.texi: Minimum version updated.
        * INSTALL: Regenerated.

13. Properly Formatted Changes

Please see Style_and_Conventions for a full description of coding guidelines.

14. Proper Formatted Unified diff of the Changes

If you have any questions regarding these criteria please email .

15. Ping and Keep Pinging

If your patch is not reviewed it may just mean that the reviewers are busy. Please ping and keep pinging the patch on a weekly basis.

None: Contribution checklist (last edited 2019-09-30 14:41:47 by SiddheshPoyarekar)