X-Git-Url: https://code.delx.au/gnu-emacs/blobdiff_plain/b41460aedee99aaf7fefe6b545a5737aa7d9d0af..fa49b46991ddc7c30c0aa526ad8966bddccc26e1:/etc/CONTRIBUTE diff --git a/etc/CONTRIBUTE b/etc/CONTRIBUTE index 99f24653ac..cba833cf58 100644 --- a/etc/CONTRIBUTE +++ b/etc/CONTRIBUTE @@ -1,5 +1,4 @@ -Copyright (C) 2006, 2007, 2008, 2009, 2010 - Free Software Foundation, Inc. +Copyright (C) 2006-2014 Free Software Foundation, Inc. See end for license conditions. @@ -23,7 +22,8 @@ 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 +documentation, find and report bugs, check if existing bug reports +are fixed in newer versions of Emacs, 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: @@ -45,13 +45,29 @@ Ref: The "Tips" Appendix in the Emacs Lisp Reference. * Copyright Assignment -We can accept small changes (roughly, fewer than 15 lines) without -legal papers. Anything more substantial requires a copyright -disclaimer or assignment (the latter is preferred, especially for -larger changes). Both of these involved filling out a short form and -filing it with the FSF. The process is straightforward -- contact us -at emacs-devel@gnu.org to obtain the relevant forms. +The FSF (Free Software Foundation) is the copyright holder for GNU Emacs. +The FSF is a nonprofit with a worldwide mission to promote computer +user freedom and to defend the rights of all free software users. +For general information, see the website http://www.fsf.org/ . + +Generally speaking, for non-trivial contributions to GNU Emacs we +require that the copyright be assigned to the FSF. For the reasons +behind this, see: http://www.gnu.org/licenses/why-assign.html . + +Copyright assignment is a simple process. If you live in the US, you +can do it entirely electronically. We can help you get started, and +answer any questions you may have (or point you to the people with the +answers), at the emacs-devel@gnu.org mailing list. +A copyright disclaimer is also a possibility, but we prefer an assignment. +Note that the disclaimer, like an assignment, involves you sending +signed paperwork to the FSF (simply saying "this is in the public domain" +is not enough). Also, a disclaimer cannot be applied to future work, it +has to be repeated each time you want to send something new. + +We can accept small changes (roughly, fewer than 15 lines) without +an assignment. This is a cumulative limit (e.g. three separate 5 line +patches) over all your contributions. * Getting the Source Code @@ -61,8 +77,8 @@ latest version. If you start from an older version, your patch may be outdated (so that maintainers will have a hard time applying it), or changes in Emacs may have made your patch unnecessary. -After you have downloaded the Bazaar source, you should read the file -INSTALL.BZR for build instructions (they differ to some extent from a +After you have downloaded the repository source, you should read the file +INSTALL.REPO for build instructions (they differ to some extent from a normal build). Ref: http://savannah.gnu.org/projects/emacs @@ -74,14 +90,16 @@ 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 bug-gnu-emacs@gnu.org or emacs-devel@gnu.org. - -All subsequent discussion should be sent to the same mailing list. +send it to the developers. Sending it to bug-gnu-emacs@gnu.org +(which is the bug/feature list) is recommended, because that list +is coupled to a tracking system that makes it easier to locate patches. +If your patch is not complete and you think it needs more discussion, +you might want to send it to emacs-devel@gnu.org instead. If you +revise your patch, send it as a followup to the initial topic. ** Description -For bug fixes, a description of the bug and how your patch fixes this -bug. +For bug fixes, a description of the bug and how your patch fixes it. For new features, a description of the feature and your implementation. @@ -89,7 +107,7 @@ 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, +See the existing ChangeLog files for format and content. Note that, unlike some other projects, we do require ChangeLogs also for documentation, i.e. Texinfo files. @@ -98,24 +116,16 @@ Manual, for how to write good log entries. ** The patch itself. -Please use "Context Diff" format. - If you are accessing the Bazaar repository, make sure your copy is up-to-date (e.g. with `bzr pull'), then use bzr diff --no-aliases --diff-options=-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. +We prefer to get the patches as plain text, either inline (be careful +your mail client does not change line breaks) or as MIME attachments. ** Please reread your patch before submitting it. @@ -149,34 +159,28 @@ included in Emacs. ** Write access to the Emacs repository. Once you become a frequent contributor to Emacs, we can consider -giving you write access to the Bazaar repository. +giving you write access to the version-control repository. ** Emacs Mailing lists. Discussion about Emacs development takes place on emacs-devel@gnu.org. -Bug reports and feature requests are sent to bug-gnu-emacs@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. +Bug reports and fixes, feature requests and implementations should be +sent to bug-gnu-emacs@gnu.org, the bug/feature list. This is coupled +to the tracker at http://debbugs.gnu.org . +You can subscribe to the mailing lists, or see the list archives, +by following links from http://savannah.gnu.org/mail/?group=emacs . ** 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.) +Any change that matters to end-users should have a NEWS entry. +Think about whether your change requires updating the documentation +(both manuals and doc-strings). If you know it does not, mark the NEWS +entry with "---". If you know that *all* the necessary documentation +updates have been made, mark the entry with "+++". Otherwise do not mark it. ** Understanding Emacs Internals.