X-Git-Url: http://git.efficios.com/?a=blobdiff_plain;f=gdb%2FCONTRIBUTE;h=f7a4e5a30a8b244a1ea91a64a0667bb5f62473d6;hb=refs%2Fheads%2Fconcurrent-displaced-stepping-2020-04-01;hp=91e3634d4fb2138e351486ccf6c2f2e49e29d1e8;hpb=17fceda3ae9e21f8d6abc89407528fa314c2bdc8;p=deliverable%2Fbinutils-gdb.git diff --git a/gdb/CONTRIBUTE b/gdb/CONTRIBUTE index 91e3634d4f..f7a4e5a30a 100644 --- a/gdb/CONTRIBUTE +++ b/gdb/CONTRIBUTE @@ -1,160 +1,13 @@ 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. +For more information see: -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. - - -o If ``gdb/configure.in'' is modified then you don't - need to include patches to the regenerated file - ``configure''. - - The maintainer will re-generate those files - using autoconf (2.13 as of 2000-02-29). - - -o If ``gdb/gdbarch.sh'' is modified, you don't - need to include patches to the generated files - ``gdbarch.h'' and ``gdbarch.c''. - - See ``gdb/configure.in'' above. +https://sourceware.org/gdb/contribute/