Mercurial > emacs

changeset 84408:4cb995afe63d

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Move to etc.
author Juri Linkov <juri@jurta.org>
date Sun, 09 Sep 2007 11:47:47 +0000
parents 54d6b66f0b5c
children b51d0973ef37
files CONTRIBUTE
diffstat 1 files changed, 0 insertions(+), 227 deletions(-) [+]
line wrap: on
line diff
--- 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:
-