-Copyright (C) 2006-2011 Free Software Foundation, Inc.
+Copyright (C) 2006-2014 Free Software Foundation, Inc.
See end for license conditions.
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:
* 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. Residents of some countries
+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.
+
+(Please note: general discussion about why some GNU projects ask
+for a copyright assignment is off-topic for emacs-devel.
+See gnu-misc-discuss instead.)
+
+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
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
** 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.
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.
** 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.
** 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.
** 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.
HCoop / bpt / emacs.git / blobdiff