Contribution Checklist

A high-quality contribution includes the following things:

1. One Patch Per Independent Change

It is very important that independent changes be split into separate patches, as it has many advantages:

Typical examples where splitting patches up will be requested:

Also, for fixes/enhancements which you implemented in multiple logical steps, we encourage you to also submit your changes in multiple commits, each commit corresponding to each logical step. For instance, if implementing a given enhancement made you...

... submitting your changes as two patches, the first one just doing the move, and the second one making the changes after the move, will greatly simplify the review of both patches, as the second patch will clearly show what changes you made.

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

Most reviewers get a lot of email. To help them, please make <Subject> as descriptive as possible, with the most important words early on:

3. Detailed Explanation of the Patch

3.1. General requirements

3.2. ChangeLog

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

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

5. Testing

In addition, we track which files don't have copyright headers, and it improves the S/N ratio of the output of updating copyright years for each new year if every file has a copyright header. Thus a copyright header is required even for simple 3 line testcases. This GNU Copyright-Notices webpage indicates the proper format for the copyright notice and how to write the dates:

     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.

8. Attribution

9. Properly Formatted GNU ChangeLog

YYYY-MM-DD<2 spaces>John Doe<2 spaces><>
<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--->* (build_warnings): Do not use -Wformat-nonliteral
<tab--->with -Wno-format.
<tab--->* configure: Regenerate.

2013-12-12  John Doe  <>

        PR gdb/9999
        * breakpoint.c (handle_some_event): Remove reference to foo.  Call
        * (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><>
<tab--->Short explanation.
<tab--->* (install_breakpoint): Remove reference to bar.

2013-11-11  John Doe  <>

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

In your patch email you should also specify which changelog is being modified. Before the line containing the date and your name/email, add a line with the path to the changelog. If there are multiple components being updated with multiple changelog edits, split these into sections, one for each changelog:

2013-12-12  John Doe  <>

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

2013-12-12  John Doe  <>

        PR gdb/9999
        * Makefile: Test changes for awesome feature.

10. Properly Formatted Changes

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

If you have any questions regarding these criteria please email .

11. More info

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

12. Submitting patches

13. Patch status

See GDB's Patchwork instance.

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

14. Ping and keep pinging

We try to do our best, but as a volunteer-based project, unfortunately lots of patches wait a bit before review. If your patch is not reviewed it thus may just mean that the reviewers are busy.

The generally accepted ping frequency is 2 weeks after first submission, and every week thereafter.

When sending a ping, reply to the original email and add "[PING]" to the reply's subject. In other words, don't start a new email thread for the ping. See rationale here.

15. 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>
<paragraph or paragraphs describing of the change>
<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.


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


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

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

17. Bugzilla

The bug tracker is Bugzilla on New users do not have the editbugs group access which means that while they can create bugs they cannot edit any aspects of the bug once created. This is done to avoid spammers modifying existing bugs. If you need the ability to edit bugs please request it on or on IRC freenode at #gdb, the bugzilla admins and senior members of the community can grant this access once they know you're not a spammer.

None: ContributionChecklist (last edited 2017-04-26 20:14:06 by PedroAlves)

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