Keywords: ISO C++, library

Appendix A. Contributing
Prev | Part IV. Appendices | Next

# Contributing

The GNU C++ Library is part of GCC and follows the same development model, so the general rules for contributing to GCC apply. Active contributors are assigned maintainership responsibility, and given write access to the source repository. First-time contributors should follow this procedure:

## Contributor Checklist

### Reading

- Get and read the relevant sections of the C++ language specification. Copies of the full ISO 14882 standard are available on line via the ISO mirror site for committee members. Non-members, or those who have not paid for the privilege of sitting on the committee and sustained their two meeting commitment for voting rights, may get a copy of the standard from their respective national standards organization. In the USA, this national standards organization is ANSI. (And if you've already registered with them you can buy the standard on-line.)

- The library working group bugs, and known defects, can be obtained here: https://www.open-std.org/jtc1/sc22/wg21

- Peruse the GNU Coding Standards, and chuckle when you hit the part about “Using Languages Other Than C”.

- Be familiar with the extensions that preceded these general GNU rules. These style issues for libstdc++ can be found in Coding Style.

- And last but certainly not least, read the library-specific information found in Porting and Maintenance.

### Assignment

See the legal prerequisites for all GCC contributions.

Historically, the libstdc++ assignment form added the following question:

“ Which Belgian comic book character is better, Tintin or Asterix, and why? ”

While not strictly necessary, humoring the maintainers and answering this question would be appreciated.

Please contact Jonathan Wakely at `<jwakely+assign@redhat.com>` if you are confused about the assignment or have general licensing questions. When requesting an assignment form from `<assign@gnu.org>`, please CC the libstdc++ maintainer above so that progress can be monitored.

### Getting Sources

Getting write access (look for "Write after approval")

### Submitting Patches

Every patch must have several pieces of information before it can be properly evaluated. Ideally (and to ensure the fastest possible response from the maintainers) it would have all of these pieces:

- A description of the bug and how your patch fixes this bug. For new features a description of the feature and your implementation.

- A ChangeLog entry as part of the Git commit message. Check some recent commits for format and content. The `contrib/mklog.py` script can be used to generate a ChangeLog template for commit messages. See Read-write Git access for scripts and aliases that are useful here.

- A testsuite submission or sample program that will easily and simply show the existing error or test new functionality.

- The patch itself. If you are using the Git repository use git show or git format-patch to produce a patch; otherwise, use diff -cp OLD NEW. If your version of diff does not support these options, then get the latest version of GNU diff.

- When you have all these pieces, bundle them up in a mail message and send it to libstdc++@gcc.gnu.org. All patches and related discussion should be sent to the libstdc++ mailing list. In common with the rest of GCC, patches should also be sent to the gcc-patches mailing list. So you could send your email To:libstdc++@gcc.gnu.org and Cc:gcc-patches@gcc.gnu.org for example.

Prev | Up | Next
Part IV. Appendices | Home | Directory Layout and Source Conventions