Explain how to contribute to GDB.

1 files changed, 146 insertions, 0 deletions

diff --git a/gdb/CONTRIBUTE b/gdb/CONTRIBUTE
new file mode 100644
index 00000000000..be6c309f8e4
--- /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.
+