view CONTRIBUTE @ 71604:801b0f932405

New file.
author Nick Roberts <nickrob@snap.net.nz>
date Tue, 04 Jul 2006 01:16:51 +0000
parents
children e4b43205e213
line wrap: on
line source


			Contributing to Emacs

Emacs is a collaborative project and one which wants to encourage new
development.  You may wish to fix Emacs bugs, improve testing, port
Emacs to a new platform, update documentation, add new Emacs features,
and the like.  To help with this, there is a lot of documentation
available.  In addition to the user guide and Lisp Reference Manual in
the Emacs distribution, the Emacs 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 Emacs (see below).

If you don't feel up to hacking Emacs, there are still plenty of ways to
help!  You can answer questions on the mailing lists, write
documentation, find bugs, create a Emacs related website (contribute to
the official Emacs web site), or create a Emacs related software
package.  We welcome all of the above and feel free to ask on the Emacs
mailing lists if you are looking for feedback or for people to review a
work in progress.

Ref: http://www.gnu.org/software/emacs/

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.
	Submissions which do not conform to the standards will be
	returned with a request to reformat the changes.

	Emacs has certain additional coding requirements.

	Ref: http://www.gnu.org/prep/standards_toc.html


o	Copyright Assignment

	Before we can accept code contributions from you, we need a
	copyright assignment form filled out and filed with the FSF.

	See some documentation by the FSF for details and contact us
	via the Emacs mailing list to obtain the relevant
	forms.

	Small changes can be accepted without a copyright assignment
	form on file.

	Ref: http://www.gnu.org/prep/maintain.html#SEC6


o	Getting the Source Code

	The latest version of Emacs can be downloaded using CVS or Arch
	from the Savannah web site.  It is important that you submit
	your patch using this version, as any bug in a released version
	of Emacs may already be fixed.  It also makes it easier for
	others to test your patch,
	
	Ref: http://savannah.gnu.org/projects/emacs


o	Submitting Patches

	Every patch must have several pieces of information before we
	can properly evaluate it.

	For bug fixes, a description of the bug and how your patch fixes
	this bug.

	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 use
	"cvs update; cvs diff -cp"; else, use "diff -cp 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 emacs-pretest-bug@gnu.org or emacs-devel@gnu.org.
	All patches and related discussion should be sent to the
	emacs-pretest-bug mailinglist. 


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	Supplemental information for Emacs Developers:

	If you wish to contribute to Emacs on a regular basis then
	you may be given write access to the CVS repository.
	
	Discussion about Emacs development takes place on
	emacs-devel@gnu.org.

	Think carefully about whether your change requires updating the
	documentation.  If it does, you can either do this yourself or
	add an item to the NEWS file.

	The best way to understand Emacs Internals is to read the code
	but there is also a node "GNU Emacs Internals" in the Appendix
	of the Emacs Lisp Reference Manual that may help.

	The file DEBUG describes how to debug Emacs.

	Avoid using `defadvice' or `eval-after-load' for lisp
	code to be included in Emacs.