From: Stephen Leake Date: Fri, 5 Dec 2014 19:13:55 +0000 (-0600) Subject: preparing for further changes/cleanup to developers/contributors docs X-Git-Tag: emacs-25.0.90~2635^2~185 X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=7409a79b1b2acf1229dd763f5eb7b96abc17113a;p=emacs.git preparing for further changes/cleanup to developers/contributors docs * etc/CONTRIBUTE: renamed to ./CONTRIBUTE, (my first commit to emacs trunk ever :) --- diff --git a/CONTRIBUTE b/CONTRIBUTE new file mode 100644 index 00000000000..b07b6c66afe --- /dev/null +++ b/CONTRIBUTE @@ -0,0 +1,227 @@ +Copyright (C) 2006-2014 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, 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: + + +* Coding Standards + +Contributed code should follow the GNU Coding Standards. + +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/ +Ref: GNU Coding Standards Info Manual +Ref: The "Tips" Appendix in the Emacs Lisp Reference. + + +* Copyright Assignment + +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 + +The latest version of the Emacs source code can be downloaded from the +Savannah web site. It is important to write your patch based on the +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 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 + + +* 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 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 it. + +For new features, a description of the feature and your implementation. + +** ChangeLog + +A ChangeLog entry as plaintext (separate from the patch). + +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. + +Ref: "Change Log Concepts" node of the GNU Coding Standards Info +Manual, for how to write good log entries. + +When using git, commit messages should use ChangeLog format, with a +single short line explaining the change, then an empty line, then +unindented ChangeLog entries. (Essentially, a commit message should +be a duplicate of what the patch adds to the ChangeLog files. We are +planning to automate this better, to avoid the duplication.) + +** The patch itself. + +If you are accessing the Emacs repository, make sure your copy is +up-to-date (e.g. with 'git pull'). You can commit your changes +to a private branch and generate a patch from the master version +by using + git format-patch master +Or you can leave your changes uncommitted and use + git diff +With no repository, you can use + diff -u OLD NEW + +** Mail format. + +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. + +** 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. + +** Do not make formatting changes. + +Making cosmetic formatting changes (indentation, etc) makes it harder +to see what you have really changed. + + +* 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 the Emacs repository. + +Once you become a frequent contributor to Emacs, we can consider +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 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. + +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. + +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. + + + +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 of the License, 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. If not, see . + +Local variables: +mode: outline +paragraph-separate: "[ ]*$" +end: diff --git a/etc/CONTRIBUTE b/etc/CONTRIBUTE deleted file mode 100644 index b07b6c66afe..00000000000 --- a/etc/CONTRIBUTE +++ /dev/null @@ -1,227 +0,0 @@ -Copyright (C) 2006-2014 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, 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: - - -* Coding Standards - -Contributed code should follow the GNU Coding Standards. - -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/ -Ref: GNU Coding Standards Info Manual -Ref: The "Tips" Appendix in the Emacs Lisp Reference. - - -* Copyright Assignment - -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 - -The latest version of the Emacs source code can be downloaded from the -Savannah web site. It is important to write your patch based on the -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 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 - - -* 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 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 it. - -For new features, a description of the feature and your implementation. - -** ChangeLog - -A ChangeLog entry as plaintext (separate from the patch). - -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. - -Ref: "Change Log Concepts" node of the GNU Coding Standards Info -Manual, for how to write good log entries. - -When using git, commit messages should use ChangeLog format, with a -single short line explaining the change, then an empty line, then -unindented ChangeLog entries. (Essentially, a commit message should -be a duplicate of what the patch adds to the ChangeLog files. We are -planning to automate this better, to avoid the duplication.) - -** The patch itself. - -If you are accessing the Emacs repository, make sure your copy is -up-to-date (e.g. with 'git pull'). You can commit your changes -to a private branch and generate a patch from the master version -by using - git format-patch master -Or you can leave your changes uncommitted and use - git diff -With no repository, you can use - diff -u OLD NEW - -** Mail format. - -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. - -** 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. - -** Do not make formatting changes. - -Making cosmetic formatting changes (indentation, etc) makes it harder -to see what you have really changed. - - -* 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 the Emacs repository. - -Once you become a frequent contributor to Emacs, we can consider -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 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. - -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. - -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. - - - -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 of the License, 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. If not, see . - -Local variables: -mode: outline -paragraph-separate: "[ ]*$" -end: