# HG changeset patch # User Juri Linkov # Date 1189338467 0 # Node ID 4cb995afe63d40d1c161d7698578ae396cf3d189 # Parent 54d6b66f0b5c44fbbd591390d3c70c3dc55ad0da Move to etc. diff -r 54d6b66f0b5c -r 4cb995afe63d CONTRIBUTE --- a/CONTRIBUTE Sun Sep 09 11:47:29 2007 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,227 +0,0 @@ -Copyright (C) 2006, 2007 Free Software Foundation, Inc. -See end for license conditions. - - - Contributing to Emacs - -Emacs is a collaborative project and we encourage contributions from -anyone and everyone. If you want to contribute in the way that will -help us most, we recommend (1) fixing reported bugs and (2) -implementing the feature ideas in etc/TODO. However, if you think of -new features to add, please suggest them too -- we might like your -idea. Porting to new platforms is also useful, when there is a new -platform, but that is not common nowadays. - -For documentation on how to develop Emacs changes, refer to the Emacs -Manual and the Emacs Lisp Reference Manual (both included in the Emacs -distribution). The web pages in http://www.gnu.org/software/emacs -contain additional information. - -You may also want to submit your change so that can be considered for -inclusion in a future version of Emacs (see below). - -If you don't feel up to hacking Emacs, there are many other ways to -help. You can answer questions on the mailing lists, write -documentation, find and report bugs, contribute to the Emacs web -pages, or develop a package that works with Emacs. - -Here are some style and legal conventions for contributors to Emacs: - - -* Coding Standards - -Contributed code should follow the GNU Coding Standard. - -If it doesn't, we'll need to find someone to fix the code before we -can use it. - -Emacs has certain additional style and coding conventions. - -Ref: http://www.gnu.org/prep/standards_toc.html -Ref: GNU Coding Standards Info Manual -Ref: The "Tips" Appendix in the Emacs Lisp Reference. - - -* Copyright Assignment - -We can accept small changes without legal papers, and for medium-size -changes a copyright disclaimer is ok too. To accept substantial -contributions from you, we need a copyright assignment form filled out -and filed with the FSF. - -Contact us at emacs-devel@gnu.org to obtain the relevant forms. - - -* Getting the Source Code - -The latest version of Emacs can be downloaded using CVS or Arch from -the Savannah web site. It is important to write your patch based on -this version; if you start from an older version, your patch may be -outdated when you write it, and maintainers will have hard time -applying it. - -After you have downloaded the CVS source, you should read the file -INSTALL.CVS for build instructions (they differ to some extent from a -normal build). - -Ref: http://savannah.gnu.org/projects/emacs - - -* Submitting Patches - -Every patch must have several pieces of information before we -can properly evaluate it. - -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 subsequent discussion should also be sent to the mailing list. - -** Description - -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. - -** ChangeLog - -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. Texinfo files. - -Ref: "Change Log Concepts" node of the GNU Coding Standards Info -Manual, for how to write good log entries. - -** The patch itself. - -Please use "Context Diff" format. - -If you are accessing the CVS repository use - cvs update; cvs diff -cp -else, use - diff -cp OLD NEW - -If your version of diff does not support these options, then get the -latest version of GNU Diff. - -** Mail format. - -We prefer to get the patches as inline plain text. - -Please be aware of line wrapping which will make the patch unreadable -and useless for us. To avoid that, you can use MIME attachments or, -as a last resort, uuencoded gzipped text. - -** Please reread your patch before submitting it. - -** Do not mix changes. - -If you send several unrelated changes together, we will ask you to -separate them so we can consider each of the changes by itself. - - -* Coding style and conventions. - -** Mandatory reading: - -The "Tips and Conventions" Appendix of the Emacs Lisp Reference. - -** Avoid using `defadvice' or `eval-after-load' for Lisp code to be -included in Emacs. - -** Remove all trailing whitespace in all source and text files. - -** Use ?\s instead of ? in Lisp code for a space character. - - -* Supplemental information for Emacs Developers. - -** Write access to Emacs' CVS repository. - -Once you become a frequent contributor to Emacs, we can consider -giving you write access to the CVS repository. - - -** Emacs Mailing lists. - -Discussion about Emacs development takes place on emacs-devel@gnu.org. - -Bug reports for released versions are sent to bug-gnu-emacs@gnu.org. - -Bug reports for development versions are sent to emacs-pretest-bug@gnu.org. - -You can subscribe to the mailing lists at savannah.gnu.org/projects/emacs. - -You can find the mailing lists archives at lists.gnu.org or gmane.org. - - -** Document your changes. - -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. - -If you document your change in NEWS, please mark the NEWS entry with -the documentation status of the change: if you submit the changes for -the manuals, mark it with "+++"; if it doesn't need to be documented, -mark it with "---"; if it needs to be documented, but you didn't -submit documentation changes, leave the NEWS entry unmarked. (These -marks are checked by the Emacs maintainers to make sure every change -was reflected in the manuals.) - - -** Understanding Emacs Internals. - -The best way to understand Emacs Internals is to read the code, -but the nodes "Tips" and "GNU Emacs Internals" in the Appendix -of the Emacs Lisp Reference Manual may also help. - -The file etc/DEBUG describes how to debug Emacs bugs. - - - -* How to Maintain Copyright Years for GNU Emacs - -See admin/notes/copyright. - -** Our lawyer says it is ok if we add, to each file that has been in Emacs -since Emacs 21 came out in 2001, all the subsequent years. We don't -need to check whether *that file* was changed in those years. -It's sufficient that *Emacs* was changed in those years (and it was!). - -** For those files that have been added since then, we should add -the year it was added to Emacs, and all subsequent years. - -** For the refcards under etc/, it's ok to simply use the latest year -(typically in a `\def\year{YEAR}' expression) for the rendered copyright -notice, while maintaining the full list of years in the copyright notice -in the comments. - - - -This file is part of GNU Emacs. - -GNU Emacs is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 3, or (at your option) -any later version. - -GNU Emacs is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License -along with GNU Emacs; see the file COPYING. If not, write to the -Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, -Boston, MA 02110-1301, USA. - -Local variables: -mode: outline -paragraph-separate: "[ ]*$" -end: -