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:

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 is the Nth version of an earlier patch:

For a patch that is already committed:

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

2. Detailed Explanation of the Patch

2.1. General requirements

2.2. ChangeLog

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

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

     Copyright (C) year copyright-holder

     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

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

11. Patch status

See GDB's Patchwork instance.

And with s/glibc/GDB/g in mind, read Patch Review Workflow.

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

13. Properly formatted commit messages

When the time comes to push your commits, please ensure the commit messages are formatted as follows:

<single line summarizing the change>
<blank-line>
<paragraph or paragraphs describing of the change>
<blank-line>
<all changelog entries relating to this change>

Remember to include the PR number (in the ChangeLog entries) if you commit is to fix a bug reported in the bugzilla.

For example:

Make all source files include defs.h or server.h first

This commit makes all source files under gdb/ that include headers
from gdb/ include either defs.h or server.h before any other code.
This ensures that definitions and macros from the two config.h files
are always in place for our code.  An exception has been made for
gdb/gdbserver/gdbreplay.c which seems to be a special case.

gdb/ChangeLog:

        * btrace.c: Include defs.h.
        * common/ptid.c: Include defs.h or server.h as appropriate.
        * nat/mips-linux-watch.c: Likewise.

gdb/gdbserver/ChangeLog:

        * hostio-errno.c: Move server.h to top of includes list.
        * inferiors.c: Likewise.
        * linux-x86-low.c: Likewise.
        * notif.c: Include server.h.

The discussions leading up to this format are in this thread and this thread.

14. Fixing commit dates

If you have used git rebase to create your commits it is likely the commit dates are wrong. Before pushing please run this command:

git rebase --ignore-date origin/master

To set the timestamps of all the commits you are about to push to the current time.

None: ContributionChecklist (last edited 2014-10-07 18:14:34 by PedroAlves)

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