This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
New file gdb/CONTRIBUTE guidelins for the contributor
- To: GDB Discussion <gdb at sourceware dot cygnus dot com>
- Subject: New file gdb/CONTRIBUTE guidelins for the contributor
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 11 Feb 2000 13:46:39 +1100
- CC: GDB Patches <gdb-patches at sourceware dot cygnus dot com>
- Organization: Cygnus Solutions
Hello,
I'd like to put the attatched file forward as an addition to the other
readme files in the GDB directory.
Originally I was going to include this in the MAINTAINERS file but
decided that a separate file was probably of more benefit and more
likely to be noticed.
In terms of content, this really is a direct lift of GCC's
how-to-contribute page.
The one problem I can see at present is that the notes don't clearly
differentiate between GDB (src/gdb) and BINUTILS (src/bfd, src/include).
Andrew
Contributing to GDB
[much of this is lifted from the GCC page]
We strongly encourage contributions of code, bugfixes, new
optimizations, new features, documentation updates, tests, web page
improvements, etc. for GDB.
There are certain legal requirements and style issues which all
contributions must meet.
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 GCC 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
gcc-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.