• Contribution checklist

Contribution Checklist

A high-quality contribution includes the following things:

Detailed Explanation of the Patch

• Explain the steps required to reproduce the problem.
• Explain the observed versus expected behaviour.
• Quote relevant standards, whenever possible give section or URL reference.

Testing

• Explain any regressions in the test suite.
• Explain for which targets the test suite was run.
• Adding a test-case to the test suite may increase the likelihood of acceptance of your patch. In some cases it may be necessary.

FSF copyright Assignment

• Explain your current FSF copyright assignment status.

Update Copyright Information

• When non-trivial, i.e. legally significant, changes are made to a file the copyright date must be updated in the file. This GNU Copyright-Notices webpage indicates the proper format for the copyright notice and how to update the dates. Here's the short of it:

1. A copyright notice takes the following form:

     Copyright (C) year1, year2, year3  copyright-holder

2. When updating the year add ', year4' following 'year3', e.g.

     Copyright (C) year1, year2, year3, year4  copyright-holder

3. Do NOT delete existing year numbers.

4. Do NOT use ranges, e.g. 1996-2004.

5. You may line wrap copyright statements if necessary, e.g.

     Copyright (C) year1, year2, year3, year4, year5, year6,
     year7, year8, year9  copyright-holder

6. Do NOT abbreviate dates into two digit year format, e.g. don't abbreviate '2000' as '08'. As indicated in this thread on libc-alpha, the maintainer does not like the two-digit year format.

Attribution

• When you create a new file you need to attribute the changes to yourself even if you submitted them on behalf of your company. Your copyright assignment is on file with the Free Software Foundation so we know who assigned the copyright to the sources you contributed, be it yourself or a company.

GNU ChangeLog

• Your ChangeLog must be in the GNU ChangeLog format. The ChangeLog format is described here and here.

• This should not be part of the change diff.

• The GDB folks have a tool called mklog to help generate ChangeLogs.

• Per this comment, Every change line in a ChangeLog should start with a capitalized word and end with a period.

• The ChangeLog should indicate what was changed in the file. For instance, if you change the size of a variable you need to indicate as much in the ChangeLog.

• ChangeLog standard tab-width is '8'.

• ChangeLog standard max-line-length is '80'.

• Make sure you mailer doesn't turn TABS into SPACES, i.e. turn on preformat.

• An example for a trivial change follows: Note: words in arrow brackets shouldn't appear in the ChangeLog, they indicate whitespace.

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 80>
<tab--->with libc internal symbol '__dup()' to avoid access through<line wrap at or before column 80>
<tab--->the PLT.

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.

Unified diff of the Changes

• Only unified diff (-uNr) format is acceptable. Patches which are context diffs will not be reviewed.

• Unified diff must be in a format that can be applied with patch -p1.
• Included inline with the text of the email or as a separate attachment if your mailer wraps long lines.

Moderation

• If your contribution is moderated please do not attempt to converse with the moderator unless you feel you've been unjustly moderated.

• Follow the instruction in the moderation email. We want to help you!

• If you need help with formulating a proper contribution, or are directed to; please use the libc-help mailing list.

• If you simply need to re-spin the patch due to some oversight please do so and resubmit to the libc-alpha mailing list as if it were an email destined for the mailing list, i.e. don't attempt to converse with the moderator or your conversational email will be moderated.

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