diff options
Diffstat (limited to 'gdb/CONTRIBUTE')
| -rw-r--r-- | gdb/CONTRIBUTE | 146 |
1 files changed, 146 insertions, 0 deletions
diff --git a/gdb/CONTRIBUTE b/gdb/CONTRIBUTE new file mode 100644 index 0000000..be6c309 --- /dev/null +++ b/gdb/CONTRIBUTE @@ -0,0 +1,146 @@ + + 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. + +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. + |