Change pointer to archived message for git-show-gnu.
|Deletions are marked like this.||Additions are marked like this.|
|Line 236:||Line 236:|
|* This should not be part of the change diff; put it right before the diff. (The [[http://news.gmane.org/find-root.php?message_id=%3C20120726215741.98FDC2C0FE@topped-with-meat.com%3E|git-show-gnu]] script can be used to produce the standard format for posting a patch once you've done a git commit on a local branch.)||* This should not be part of the change diff; put it right before the diff. (The [[http://sourceware-org.1504.n7.nabble.com/git-vs-ChangeLog-td1350.html|git-show-gnu]] script can be used to produce the standard format for posting a patch once you've done a git commit on a local branch.)|
- Bugzilla Entry
- Contribution Email Subject Line
- Properly Identified Contribution Scope
- Detailed Explanation of the Patch
- Check For New Warnings
- Try to Identify Related Changes
- FSF copyright Assignment
- Update Copyright Information
- Properly Formatted GNU ChangeLog
- Properly Formatted Changes
- Proper Formatted Unified diff of the Changes
- Ping and Keep Pinging
A contribution to the glibc project should always be sent to the appropriate mailing list for the contribution scope:
- libc-alpha (Core glibc)
- libc-locale (Locale change discussions only, send patches to libc-alpha)
- libc-stable (Discussions around stable branches and backported patches only. Send new patches to libc-alpha)
- libc-help (Need help? Any glibc question is a valid question on this list)
A high-quality contribution includes the following things:
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):
[PATCH] <Subsystem>: <Short description>
For Multi-part patch set contributions where [PATCH 0/2] is used to described the forth coming patches:
[PATCH 0/2] <Optional unique prefix e.g. "String cleanup:"><Subject related to the patch set e.g. Cleanup all broken string routines.>
[PATCH 1/2] <Optional unique prefix e.g. "String cleanup:"><Distinct subject line for this patch e.g. Cleanup strstr.>
[PATCH 2/2] <Optional unique prefix e.g. "String cleanup:"><Another distinct subject line for this patch e.g. Cleanup strncmp.>
For a request for comments that doesn't have to be a patch at all:
[RFC] <Short description>
For a request for comments on a patch or patch set:
[RFC][PATCH] <Short description>
For a patch that fixes a bug filed in bugzilla (add BZ# suffix):
[PATCH] <Subsystem>: <Short description> [BZ #NNNN]
For a patch that affects a particular architecture only (use the arch as the subsystem):
[PATCH] powerpc: <Short description>
[PATCH] aarch64: <Short description>
For a patch that is the Nth version of an earlier patch:
[PATCH vN] <Subsystem>: <Short description>
For a patch that is the Nth version of an earlier patch with multiple patches (follows the git send-email format for multiple patches):
[PATCH vN 0/25] <Subsystem>: <Short description>
For a patch carried on a non-canonical namespace branch, but not necessary in-line in the patch body:
[PATCH namespace/branch] <Subsystem>: <Short description>, e.g., [PATCH roland/arm-memcpy] ARM: Make multiarch memcpy always use NEON when compiler does
For a patch that is already committed:
[COMMITTED] <Subsystem>: <Short description>
<Subsystem>: <Short description> [committed]
4. Properly Identified Contribution Scope
As of glibc 2.27 there is only one ChangeLog file for whole project located in the base directory and all changes should be indicated in that file. However, if you want to make sure that this documentation is up-to-date or if you are working with old stable branches run find . -name ChangeLog. Normally the output should show only one file:
Please note that old stable branches may have one or more legacy ChangeLogs still in use. The find . -name ChangeLog command may show multiple ChangeLog files which help identify the scope of your contribution, e.g.,
./localedata/ChangeLog ./libidn/ChangeLog ./ChangeLog
If you've touched code in any of the directories these ChangeLogs are found you can use the directory(s) to identify the scope(s) of the patch. Please be aware of that when submitting patches to stable branches.
If you have modified code in more than one than one scope you need to generate separate patch sets and separate ChangeLog entries for each scope.
- If possible keep a patch to a single scope.
- Any modification to code not in the Add-ons scope should be considered part of glibc base scope.
- Send base scope patches to the libc-alpha mailing list.
As of glibc 2.27 the project toplevel ChangeLog is for all changes. For the old stable branches it is for anything in the base scope that doesn't have it's own ChangeLog.
All entries for the toplevel ChangeLog file should be relative to the base directory and all patches under this scope should apply with patch -p1.
4.2. Add-Ons (NPTL, localedata, posix, libidn, et al)
- Patches to add-on projects (like NPTL) should be sent to the libc-alpha mailing list.
As of glibc 2.27 any changes to the add-on directory should be indicated in the project toplevel ChangeLog file.
On old stable branches some add-ons have their own ChangeLog files so any changes to the add-on directory should be indicated in <add-on>/ChangeLog.
On old stable branches only: all entries for the <add-on>/ChangeLog file should be relative to the <add-on>/ directory.
All Add-on patches should apply with patch -p0 from the base glibc directory.
For locale changes to the Localedata add-on please see the Qualifications section in the Locales page.
The ports/ directory is no longer used as of glibc 2.20. All code has been merged into the core project. If you have patches for ports/ please rebase them against the appropriate new directories.
For patches to stable branches that still use ports/ please send ports patches to the libc-alpha mailing list.
On old stable branches the ports/ project has its own ChangeLog file so any changes to a ports platform should be indicated in the ports/ChangeLog.
All entries for the ports/ChangeLog file should be relative to the ports/ directory and all patches should apply with patch -p1.
4.4. Out-of-Scope (Automatically Generated Files)
Changes in automatically regenerated files (configure, for example) should not be included in the submitted patch.
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
- Explain the steps required to reproduce the problem.
- Extra points are awarded for a test-case which demonstrates the problem and can be used in the test-suite to demonstrate success of a fix.
- Explain the observed versus expected behaviour.
- Quote relevant standards, whenever possible give section or URL reference.
All patches for consideration must have ChangeLog entry updates (see below).
If the code in question is a Request For Comment (RFC) please indicate as such in the email subject. Explicit RFC emails aren't constrained by the ChangeLog rules but they won't be considered for inclusion until they comply.
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/
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.
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. All test cases begin with a comment that contains a one line explanation of the test and the FSF copyright header.
7.1. Testing Locales
Please see the Testing Locales section in the Locales page.
8. Try to Identify Related Changes
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.
9. FSF copyright Assignment
The Free Software Foundation (holder of the glibc copyrights) requires copyright assignment for all legally significant changes by a particular author (read not a company). This webpage describes the copyright assignment requirements.
- Explain your current FSF copyright assignment status.
In the event that you have not previously completed an FSF copyright assignment, a glibc developer or project steward can direct you to a FSF copyright assignment request form that's best suited to your contribution under the guidelines on this gnu.org webpage. To find a glibc maintainer or project steward see the MAINTAINERS page or ask for help on libc-help.
Copyright assignment is not required for localedata changes.
10. 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:
- A copyright notice takes the following form:
Copyright (C) year1, year5 copyright-holder
To add 'year6' following 'year5' simply add ', year6' between 'year5' and the copyright-holder, e.g.,:
Copyright (C) year1, year5, year6 copyright-holder
For glibc, spanning of consecutive years IS allowed. Therefore, when adding a third (or more) consecutive year to the copyright statement (like 'year7'), you may replace individual consecutive years with a year range, e.g.,
Copyright (C) year1, year5-year7 copyright-holder
For glibc, collapsing of years between 1991 and the present IS allowed (See this thread on libc-alpha). Therefore, when adding a second (or more) years to the copyright statement (like 'year7'), you may collapse years with a year range given that the range starts at or after 1991, e.g.,
Copyright (C) year1-year7 copyright-holder
Do NOT abbreviate dates into two digit year format, i.e., don't abbreviate '2008' as '08'. As indicated in this thread on libc-alpha, the maintainer does not like the two-digit year format.
- The copyright notice of some files indicates a copyright holder other than the FSF (such files have been copied from another project). In those cases, leave the the non-FSF copyright notice as is, and add a new line for the FSF copyright. If there's already an FSF-copyright line, simply update it, adding it a year as usual. If the two copyright notices disagree for other reasons, e.g., licensing information, keep the notices separate. E.g.,
Copyright (C) 2012-2013 Free Software Foundation, Inc. ... rest of FSF copyright notice ... Copyright (C) 2010 other-copyright-holder ... rest of other copyright notice ...
"Contributed by" statements are no longer required or desired in glibc source files (though existing statements will remain). Attribution is now recorded in git commit logs as the commit "Author". Please do not use "Contributed by" statements in your submissions.
12. Properly Formatted GNU ChangeLog
This should not be part of the change diff; put it right before the diff. (The git-show-gnu script can be used to produce the standard format for posting a patch once you've done a git commit on a local branch.)
- Files that were regenerated should be identified and the change should say "Regenerated."
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 your 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.
When multiple entries contain the same ChangeLog information as previous entries the glibc approved shorthand is: * file: Likewise.
YYYY-MM-DD<2 spaces>John Doe<2 spaces><email@example.com> <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 <firstname.lastname@example.org> [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
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.
- The strong preference is that you include the patch as part of the text of the email. However, if your mailer unavoidably wraps long lines or otherwise alters patch contents, or if the diff might cause problems due to binary data or mixed encodings, attach the patch to the email. The attachment should normally employ a Content-Type of text/x-diff or text/x-patch (or at least text/plain) and a charset of UTF-8 or US-ASCII; if it contains binary data or mixed encoding it may need to specify a Content-Type of application/octet-stream instead. Please use an attachment file name that ends in ".diff" or ".patch" (or at least ".txt").
Only one patch per email. Patchsets should be numbered to allow for committers to easily pull patches from patchwork and apply them in sequence for testing. Please do not attach more than one patch per email since patchwork does not support this. In general this follows the git send-email format.
If you have any questions regarding these criteria please email email@example.com .
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.