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

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 Changes

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

If you have any questions regarding these criteria please email .

10. Submitting patches

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

12. Properly formatted commit messages

Please ensure the commit messages are formatted as follows (following common git conventions):

<single line summarizing the change>
<paragraphs describing of the change>
<git trailers>

The first line (which will also be the email's subject when sending the patch with git-send-email), should be as concise as possible while being precise enough to know what the patch is about. It's the one line sales pitch of your patch. There is no strict maximum length, but over 80 characters is getting a bit long.

Git trailers are metadata lines often found at the end of git commit messages, of the form Key: Value. The ones we use are:

For example (the bug number is made up):

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.

Co-Authored-By: Janine Sutto <>

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

14. 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 2022-04-01 14:18:41 by SimonMarchi)

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