Contributing to GDB
-GDB is a collaborative project and one which wants to encourage new
-development. You may wish to fix GDB bugs, improve testing, port GDB
-to a new platform, update documentation, add new GDB features, and the
-like. To help with this, there is a lot of documentation
-available.. In addition to the user guide and internals manual
-included in the GDB distribution, the GDB web pages also contain much
-information.
+GDB is a collaborative project that relies on contributions. You can
+help with this! You may wish to fix bugs, improve testing, port GDB to
+a new platform, update documentation, add new features or optimizations,
+contribute to the mailing lists or official GDB website, etc. We welcome
+all of the above and feel free to ask on the GDB mailing lists if you are
+looking for feedback or for people to review a work in progress.
-You may also want to submit your change so that can be considered for
-conclusion in a future version of GDB (see below). Regardless, we
-encourage you to distribute the change yourself.
-
-If you don't feel up to hacking GDB, there are still plenty of ways to
-help! You can answer questions on the mailing lists, write
-documentation, find bugs, create a GDB related website (contribute to
-the official GDB web site), or create a GDB related software
-package. We welcome all of the above and feel free to ask on the GDB
-mailing lists if you are looking for feedback or for people to review
-a work in progress.
-
-Ref: http://sourceware.cygnus.com/gdb
-
-Finally, there are certain legal requirements and style issues which
-all contributors need to be aware of.
-
-o Coding Standards
-
- All contributions must conform to the GNU Coding Standard.
- http://www.gnu.ai.mit.edu/prep/standards_toc.html
- Submissions which do not conform to the standards will be
- returned with a request to reformat the changes.
-
- For GDB, that standard is more tightly defined. GDB's
- coding standard is determined by the output of
- gnu-indent.
-
- This situation came about because, by the start of '99,
- GDB's coding style was so bad an inconsistent that it was
- decided to restart things from scratch.
-
-
-o Copyright Assignment
-
- There are certain legal requirements
-
- Before we can accept code contributions from you, we need a
- copyright assignment form filled out.
-
- If you've developed some addition or patch to GDB that you
- would like to contribute, you should fill out a copyright
- assignment form and send it in to the FSF. We are unable to
- use code from you until this is on-file at the FSF, so get
- that paperwork in! This form covers one batch of changes.
- Ref: http://gcc.gnu.org/fsf-forms/assignment-instructions.html
-
- If you think you're going to be doing continuing work on GDB, it
- would be easier to use a different form, which arranges to
- assign the copyright for all your future changes to GDB. It is
- called assign.future. Please note that if you switch
- employers, the new employer will need to fill out the
- disclaim.future form; there is no need to fill out the
- assign.future form again.
- Ref: http://gcc.gnu.org/fsf-forms/assign.future
- Ref: http://gcc.gnu.org/fsf-forms/disclaim.future
-
- There are several other forms you can fill out for different
- circumstances (e.g. to contribute an entirely new program, to
- contribute significant changes to a manual, etc.)
- Ref: http://gcc.gnu.org/fsf-forms/copyrights.html
-
- Small changes can be accepted without a copyright assignment
- form on file.
-
- This is pretty confusing! If you are unsure of what is
- necessary, just ask the GDB mailing list and we'll figure out
- what is best for you.
-
- Note: Many of these forms have a place for "name of
- program". Insert the name of one program in that place -- in
- this case, "GDB".
-
-
-o Submitting Patches
-
- Every patch must have several pieces of information before we
- can properly evaluate it.
-
- A description of the bug and how your patch fixes this
- bug. A reference to a testsuite failure is very helpful. For
- new features a description of the feature and your
- implementation.
-
- A ChangeLog entry as plaintext (separate from the patch); see
- the various ChangeLog files for format and content. Note that,
- unlike some other projects, we do require ChangeLogs also for
- documentation (i.e., .texi files).
-
- The patch itself. If you are accessing the CVS repository at:
- Cygnus, use "cvs update; cvs diff -c3p"; else, use "diff -c3p
- OLD NEW" or "diff -up OLD NEW". If your version of diff does
- not support these options, then get the latest version of GNU
- diff.
-
- We accept patches as plain text (preferred for the compilers
- themselves), MIME attachments (preferred for the web pages),
- or as uuencoded gzipped text.
-
- When you have all these pieces, bundle them up in a mail
- message and send it to gdb-patches@sourceware.cygnus.com. All
- patches and related discussion should be sent to the
- gdb-patches mailinglist. For further information on the GDB
- CVS repository, see the Anonymous read-only CVS access and
- Read-write CVS access page.
-
---
-
-Supplemental information for GDB:
-
-o Please try to run the relevant testsuite before and after
- committing a patch
-
- If the contributor doesn't do it then the maintainer will. A
- contributor might include before/after test results in their
- contribution.
-
-
-o For bug fixes, please try to include a way of
- demonstrating that the patch actually fixes something.
-
- The best way of doing this is to ensure that the
- testsuite contains one or more test cases that
- fail without the fix but pass with the fix.
-
- People are encouraged to submit patches that extend
- the testsuite.
-
-
-o Please read your patch before submitting it.
-
- A patch containing several unrelated changes or
- arbitrary reformats will be returned with a request
- to re-formatting / split it.
+For more information see:
+https://sourceware.org/gdb/contribute/
projects / deliverable / binutils-gdb.git / blobdiff