Differences between revisions 17 and 18
Revision 17 as of 2013-05-20 15:31:12
Size: 10353
Editor: PedroAlves
Comment: Split paragraph into bullets, so the middle sentence isn't easilly missed.
Revision 18 as of 2013-05-25 15:09:21
Size: 10429
Editor: PedroAlves
Comment: Add link to the testcase cookbook.
Deletions are marked like this. Additions are marked like this.
Line 99: Line 99:

 * See [[GDBTestcaseCookbook|here for a cookbook on writing GDB tests]].

Contribution Checklist

A high-quality contribution includes the following things:

1. Contribution Email Subject Line

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

For a Single patch contribution:

  • [PATCH] <Subject>

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] <Subject>

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

  • [RFC][PATCH] <Subject>

For a patch that fixes a bug filed in bugzilla:

  • [PATCH][PR <component/number>] <Subject>

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

  • [PATCH vN] <Subject>

For a patch that is already committed:


For a patch that falls under the The Obvious Rule as described in gdb/MAINTAINERS:

  • [OB PATCH] ...

2. Detailed Explanation of the Patch

2.1. General requirements

  • Describe the rationale for the patch. E.g., don't assume the change will be obvious to others just because it's a small patch. It may be that it only looks obvious to you, because you've spent the effort investigating the issue, and you have all the context in your head. Your job is to make it easy for the reviewer to give you an OK.
  • If you experimented other seemingly valid or seemingly better approaches for your fix/feature, and they didn't work out, mention it in the patch submission, along with the reason for why it didn't work out.
  • 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. If you're changing the output of some command, include a paste of the relevant parts of gdb session, before and after the change.

2.2. ChangeLog

All patches for consideration must have ChangeLog entry updates (see below) of they will be rejected during mailing list moderation.

  • Run find . -name ChangeLog to help identify the correct ChangeLog file. E.g.,

    • ./ChangeLog
  • This should not be part of the change diff; paste it in clear text in the body of the email.
  • When posting a new version of a patch, either as a new thread, or in reply to an existing thread, always repost the ChangeLog entry as well, even if it hasn't changed.

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

3. Documentation

If your patch adds a new command then that command should be documented in the GDB manual, and mentioned in the NEWS file. All commands must be documented, including maintenance commands (e.g., "set debug" or "maint" commands).

New target ports must be mentioned in the NEWS file.

New host configurations must be mentioned in the NEWS file.

New remote protocol packets must be documented in the GDB manual, and mentioned in the NEWS file.

Standard target features for xml target descriptions (e.g., org.gnu.gdb.arm.core, org.gnu.gdb.i386.sse) must be documented in the GDB manual.

New MI commands, attributes, etc., must be documented in the GDB manual, and mentioned in the NEWS file.

New Python scripting features must be documented in the GDB manual, and mentioned in the NEWS file.

4. Testing

  • Make sure there are no 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 many cases it will be necessary.
  • See here for a cookbook on writing GDB tests.

  • Explain your current FSF copyright assignment status.
  • In the event that you have not previously completed an FSF copyright assignment, a GDB maintainer will direct you to a FSF copyright assignment request form that's best suited to your contribution under the guidelines on this gnu.org webpage.

  • All source files must have a copyright header. Although the FSF only requires that for legally significant files (IOW, files with only a couple lines wouldn't require a header), GDB maintainers prefer not having to worry about later having to add the header when the file grows. This GNU Copyright-Notices webpage indicates the proper format for the copyright notice and how to write the dates:

  • A copyright notice takes the following form:

     Copyright (C) year copyright-holder
  • For GDB, spanning of consecutive years IS allowed. Therefore, when adding a second (or more) consecutive year to the copyright statement, you may write a year range, e.g.,

     Copyright (C) year1-year2 copyright-holder

The simplest is to just copy the header from some other file.

If you've based your new file on some other file, as e.g., it is common to do when writing new tests, then the copyright years of the original file must be retained in the new file.

7. Properly Formatted GNU ChangeLog

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

  • Files that were regenerated should be identified and the change should say "Regenerate."
  • The GCC folks have a tool called mklog to help generate ChangeLogs. This script creates a ChangeLog template for a diff file. Run "mklog diff-file" and the template will be added to the top of the file.

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

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

YYYY-MM-DD<2 spaces>John Doe<2 spaces><johndoe@some.email.address>
<tab--->PR <component>/<number><use this if there is a bugzilla PR associated with the patch>
<tab--->* breakpoint.c (handle_some_event): Remove reference to foo.  Call<line wrap at or before column 74>
<tab--->* configure.ac (build_warnings): Do not use -Wformat-nonliteral
<tab--->with -Wno-format.
<tab--->* configure: Regenerate.

2013-12-12  John Doe  <johndoe@some.email.address>

        PR gdb/9999
        * breakpoint.c (handle_some_event): Remove reference to foo.  Call
        * configure.ac (build_warnings): Do not use -Wformat-nonliteral
        with -Wno-format.
        * configure: Regenerate.
        * NEWS: Mention awesome feature.

It's okay (and not uncommon) to include a one sentence explanation to the patch as a whole, in addition or in place of "PR comp/xyz". E.g.,

YYYY-MM-DD<2 spaces>John Doe<2 spaces><johndoe@some.email.address>
<tab--->Short explanation.
<tab--->* (install_breakpoint): Remove reference to bar.

2013-11-11  John Doe  <johndoe@some.email.address>

        Code cleanup.
        * breakpoint.c (install_breakpoint): Remove reference to bar.

8. Properly Formatted Changes

Please see Coding Standards for a full description of coding guidelines.

See also JoelsCodingStyleCheatSheet for very common nits.

If you have any questions regarding these criteria please email gdb-patches@sourceware.org .

9. More info

The file <gdb-src>/gdb/CONTRIBUTE contains more instructions on what is expected from patches submitted to GDB.

10. 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: ContributionChecklist (last edited 2018-05-24 12:04:23 by PedroAlves)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.