Contribution Checklist

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

A high-quality contribution includes the following things:

1. 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.

Please follow the bugzilla procedures.

2. Contribution Email Subject Line

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

For a Single patch contribution:

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:

For a patch that affects a particular architecture only:

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

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:

3. Properly Identified Contribution Scope

3.1. Base

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

3.3. Ports

3.4. Out-of-Scope (Automatically Generated Files)

Changes in automatically regenerated files (configure, for example) should not be included in the submitted patch.

4. Detailed Explanation of the Patch

4.1. General Patch Requirements

4.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: http://www.kernel.org/doc/man-pages/

5. 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.

6. Testing

6.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.

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

10. Attribution

11. Properly Formatted GNU ChangeLog

YYYY-MM-DD<2 spaces>John Doe<2 spaces><johndoe@some.email.address>
<blank-line>
<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  <johndoe@some.email.address>

        [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.

12. Properly Formatted Changes

Please see Style_and_Conventions for a full description of coding guidelines.

13. Proper Formatted Unified diff of the Changes

If you have any questions regarding these criteria please email libc-help@sourceware.org .

14. 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 2013-10-15 14:02:32 by MarkoMyllynen)