gdb/CONTRIBUTE

   1
   2                         Contributing to GDB
   3
   4 GDB is a collaborative project and one which wants to encourage new
   5 development.  You may wish to fix GDB bugs, improve testing, port GDB
   6 to a new platform, update documentation, add new GDB features, and the
   7 like. To help with this, there is a lot of documentation
   8 available.. In addition to the user guide and internals manual
   9 included in the GDB distribution, the GDB web pages also contain much
  10 information.
  11
  12 You may also want to submit your change so that can be considered for
  13 conclusion in a future version of GDB (see below).  Regardless, we
  14 encourage you to distribute the change yourself.
  15
  16 If you don't feel up to hacking GDB, there are still plenty of ways to
  17 help!  You can answer questions on the mailing lists, write
  18 documentation, find bugs, create a GDB related website (contribute to
  19 the official GDB web site), or create a GDB related software
  20 package. We welcome all of the above and feel free to ask on the GDB
  21 mailing lists if you are looking for feedback or for people to review
  22 a work in progress.
  23
  24 Ref: http://www.gnu.org/software/gdb/
  25
  26 Finally, there are certain legal requirements and style issues which
  27 all contributors need to be aware of.
  28
  29 o       Coding Standards
  30
  31         All contributions must conform to the GNU Coding Standard.
  32         Submissions which do not conform to the standards will be
  33         returned with a request to reformat the changes.
  34
  35         GDB has certain additional coding requirements.  Those
  36         requirements are explained in the GDB internals documentation
  37         in the gdb/doc directory.
  38
  39         Ref: http://www.gnu.org/prep/standards_toc.html
  40
  41
  42 o       Copyright Assignment
  43
  44         Before we can accept code contributions from you, we need a
  45         copyright assignment form filled out and filed with the FSF.
  46
  47         See some documentation by the FSF for details and contact us
  48         (either via the GDB mailing list or the GDB maintainer that is
  49         taking care of your contributions) to obtain the relevant
  50         forms.
  51
  52         Small changes can be accepted without a copyright assignment form on file.
  53
  54         Ref: http://www.gnu.org/prep/maintain.html#SEC6
  55
  56
  57 o       Submitting Patches
  58
  59         Every patch must have several pieces of information before we
  60         can properly evaluate it.
  61
  62         A description of the bug and how your patch fixes this
  63         bug. A reference to a testsuite failure is very helpful. For
  64         new features a description of the feature and your
  65         implementation.
  66
  67         A ChangeLog entry as plaintext (separate from the patch); see
  68         the various ChangeLog files for format and content. Note that,
  69         unlike some other projects, we do require ChangeLogs also for
  70         documentation (i.e., .texi files).
  71
  72         The patch itself. If you are accessing the CVS repository use
  73         "cvs update; cvs diff -c3p"; else, use "diff -c3p OLD NEW" or
  74         "diff -up OLD NEW". If your version of diff does not support
  75         these options, then get the latest version of GNU diff.
  76
  77         We accept patches as plain text (preferred for the compilers
  78         themselves), MIME attachments (preferred for the web pages),
  79         or as uuencoded gzipped text.
  80
  81         When you have all these pieces, bundle them up in a mail
  82         message and send it to gdb-patches@sources.redhat.com. All
  83         patches and related discussion should be sent to the
  84         gdb-patches mailinglist. For further information on the GDB
  85         CVS repository, see the Anonymous read-only CVS access and
  86         Read-write CVS access page.
  87
  88 --
  89
  90 Supplemental information for GDB:
  91
  92 o       Please try to run the relevant testsuite before and after
  93         committing a patch
  94
  95         If the contributor doesn't do it then the maintainer will.  A
  96         contributor might include before/after test results in their
  97         contribution.
  98
  99
 100 o       For bug fixes, please try to include a way of
 101         demonstrating that the patch actually fixes something.
 102
 103         The best way of doing this is to ensure that the
 104         testsuite contains one or more test cases that
 105         fail without the fix but pass with the fix.
 106
 107         People are encouraged to submit patches that extend
 108         the testsuite.
 109
 110
 111 o       Please read your patch before submitting it.
 112
 113         A patch containing several unrelated changes or
 114         arbitrary reformats will be returned with a request
 115         to re-formatting / split it.
 116
 117
 118 o       If ``gdb/configure.in'' is modified then you don't
 119         need to include patches to the regenerated file
 120         ``configure''.
 121
 122         The maintainer will re-generate those files
 123         using autoconf (2.13 as of 2000-02-29).
 124
 125
 126 o       If ``gdb/gdbarch.sh'' is modified, you don't
 127         need to include patches to the generated files
 128         ``gdbarch.h'' and ``gdbarch.c''.
 129
 130         See ``gdb/configure.in'' above.
 131
 132
 133 o       When submitting a patch that fixes a bug
 134         in GDB's bug database a brief reference
 135         to the bug can be included in the ChangeLog
 136         vis
 137
 138         * CONTRIBUTE: Mention PR convention.
 139         Fix PR gdb/4705.
 140
 141         The text ``PR gdb/4705'' should also be included
 142         in the CVS commit message.  That causes the
 143         patch to automatically be archived with the PR.