aboutsummaryrefslogtreecommitdiffstats
path: root/etc
diff options
context:
space:
mode:
Diffstat (limited to 'etc')
-rw-r--r--etc/CONTRIBUTE227
-rw-r--r--etc/refcards/emacsver.tex4
2 files changed, 231 insertions, 0 deletions
diff --git a/etc/CONTRIBUTE b/etc/CONTRIBUTE
new file mode 100644
index 00000000000..92b4c9e4ce2
--- /dev/null
+++ b/etc/CONTRIBUTE
@@ -0,0 +1,227 @@
1Copyright (C) 2006-2015 Free Software Foundation, Inc.
2See end for license conditions.
3
4
5 Contributing to Emacs
6
7Emacs is a collaborative project and we encourage contributions from
8anyone and everyone. If you want to contribute in the way that will
9help us most, we recommend (1) fixing reported bugs and (2)
10implementing the feature ideas in etc/TODO. However, if you think of
11new features to add, please suggest them too -- we might like your
12idea. Porting to new platforms is also useful, when there is a new
13platform, but that is not common nowadays.
14
15For documentation on how to develop Emacs changes, refer to the Emacs
16Manual and the Emacs Lisp Reference Manual (both included in the Emacs
17distribution). The web pages in http://www.gnu.org/software/emacs
18contain additional information.
19
20You may also want to submit your change so that can be considered for
21inclusion in a future version of Emacs (see below).
22
23If you don't feel up to hacking Emacs, there are many other ways to
24help. You can answer questions on the mailing lists, write
25documentation, find and report bugs, check if existing bug reports
26are fixed in newer versions of Emacs, contribute to the Emacs web
27pages, or develop a package that works with Emacs.
28
29Here are some style and legal conventions for contributors to Emacs:
30
31
32* Coding Standards
33
34Contributed code should follow the GNU Coding Standards.
35
36If it doesn't, we'll need to find someone to fix the code before we
37can use it.
38
39Emacs has certain additional style and coding conventions.
40
41Ref: http://www.gnu.org/prep/standards/
42Ref: GNU Coding Standards Info Manual
43Ref: The "Tips" Appendix in the Emacs Lisp Reference.
44
45
46* Copyright Assignment
47
48The FSF (Free Software Foundation) is the copyright holder for GNU Emacs.
49The FSF is a nonprofit with a worldwide mission to promote computer
50user freedom and to defend the rights of all free software users.
51For general information, see the website http://www.fsf.org/ .
52
53Generally speaking, for non-trivial contributions to GNU Emacs we
54require that the copyright be assigned to the FSF. For the reasons
55behind this, see: http://www.gnu.org/licenses/why-assign.html .
56
57Copyright assignment is a simple process. Residents of some countries
58can do it entirely electronically. We can help you get started, and
59answer any questions you may have (or point you to the people with the
60answers), at the emacs-devel@gnu.org mailing list.
61
62(Please note: general discussion about why some GNU projects ask
63for a copyright assignment is off-topic for emacs-devel.
64See gnu-misc-discuss instead.)
65
66A copyright disclaimer is also a possibility, but we prefer an assignment.
67Note that the disclaimer, like an assignment, involves you sending
68signed paperwork to the FSF (simply saying "this is in the public domain"
69is not enough). Also, a disclaimer cannot be applied to future work, it
70has to be repeated each time you want to send something new.
71
72We can accept small changes (roughly, fewer than 15 lines) without
73an assignment. This is a cumulative limit (e.g. three separate 5 line
74patches) over all your contributions.
75
76* Getting the Source Code
77
78The latest version of the Emacs source code can be downloaded from the
79Savannah web site. It is important to write your patch based on the
80latest version. If you start from an older version, your patch may be
81outdated (so that maintainers will have a hard time applying it), or
82changes in Emacs may have made your patch unnecessary.
83
84After you have downloaded the repository source, you should read the file
85INSTALL.REPO for build instructions (they differ to some extent from a
86normal build).
87
88Ref: http://savannah.gnu.org/projects/emacs
89
90
91* Submitting Patches
92
93Every patch must have several pieces of information before we
94can properly evaluate it.
95
96When you have all these pieces, bundle them up in a mail message and
97send it to the developers. Sending it to bug-gnu-emacs@gnu.org
98(which is the bug/feature list) is recommended, because that list
99is coupled to a tracking system that makes it easier to locate patches.
100If your patch is not complete and you think it needs more discussion,
101you might want to send it to emacs-devel@gnu.org instead. If you
102revise your patch, send it as a followup to the initial topic.
103
104** Description
105
106For bug fixes, a description of the bug and how your patch fixes it.
107
108For new features, a description of the feature and your implementation.
109
110** ChangeLog
111
112A ChangeLog entry as plaintext (separate from the patch).
113
114See the existing ChangeLog files for format and content. Note that,
115unlike some other projects, we do require ChangeLogs also for
116documentation, i.e. Texinfo files.
117
118Ref: "Change Log Concepts" node of the GNU Coding Standards Info
119Manual, for how to write good log entries.
120
121When using git, commit messages should use ChangeLog format, with a
122single short line explaining the change, then an empty line, then
123unindented ChangeLog entries. (Essentially, a commit message should
124be a duplicate of what the patch adds to the ChangeLog files. We are
125planning to automate this better, to avoid the duplication.)
126
127** The patch itself.
128
129If you are accessing the Emacs repository, make sure your copy is
130up-to-date (e.g. with 'git pull'). You can commit your changes
131to a private branch and generate a patch from the master version
132by using
133 git format-patch master
134Or you can leave your changes uncommitted and use
135 git diff
136With no repository, you can use
137 diff -u OLD NEW
138
139** Mail format.
140
141We prefer to get the patches as plain text, either inline (be careful
142your mail client does not change line breaks) or as MIME attachments.
143
144** Please reread your patch before submitting it.
145
146** Do not mix changes.
147
148If you send several unrelated changes together, we will ask you to
149separate them so we can consider each of the changes by itself.
150
151** Do not make formatting changes.
152
153Making cosmetic formatting changes (indentation, etc) makes it harder
154to see what you have really changed.
155
156
157* Coding style and conventions.
158
159** Mandatory reading:
160
161The "Tips and Conventions" Appendix of the Emacs Lisp Reference.
162
163** Avoid using `defadvice' or `eval-after-load' for Lisp code to be
164included in Emacs.
165
166** Remove all trailing whitespace in all source and text files.
167
168** Use ?\s instead of ? in Lisp code for a space character.
169
170
171* Supplemental information for Emacs Developers.
172
173** Write access to the Emacs repository.
174
175Once you become a frequent contributor to Emacs, we can consider
176giving you write access to the version-control repository.
177
178
179** Emacs Mailing lists.
180
181Discussion about Emacs development takes place on emacs-devel@gnu.org.
182
183Bug reports and fixes, feature requests and implementations should be
184sent to bug-gnu-emacs@gnu.org, the bug/feature list. This is coupled
185to the tracker at http://debbugs.gnu.org .
186
187You can subscribe to the mailing lists, or see the list archives,
188by following links from http://savannah.gnu.org/mail/?group=emacs .
189
190** Document your changes.
191
192Any change that matters to end-users should have a NEWS entry.
193
194Think about whether your change requires updating the documentation
195(both manuals and doc-strings). If you know it does not, mark the NEWS
196entry with "---". If you know that *all* the necessary documentation
197updates have been made, mark the entry with "+++". Otherwise do not mark it.
198
199** Understanding Emacs Internals.
200
201The best way to understand Emacs Internals is to read the code,
202but the nodes "Tips" and "GNU Emacs Internals" in the Appendix
203of the Emacs Lisp Reference Manual may also help.
204
205The file etc/DEBUG describes how to debug Emacs bugs.
206
207
208
209This file is part of GNU Emacs.
210
211GNU Emacs is free software: you can redistribute it and/or modify
212it under the terms of the GNU General Public License as published by
213the Free Software Foundation, either version 3 of the License, or
214(at your option) any later version.
215
216GNU Emacs is distributed in the hope that it will be useful,
217but WITHOUT ANY WARRANTY; without even the implied warranty of
218MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
219GNU General Public License for more details.
220
221You should have received a copy of the GNU General Public License
222along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
223
224Local variables:
225mode: outline
226paragraph-separate: "[ ]*$"
227end:
diff --git a/etc/refcards/emacsver.tex b/etc/refcards/emacsver.tex
new file mode 100644
index 00000000000..8b6e8c41e8b
--- /dev/null
+++ b/etc/refcards/emacsver.tex
@@ -0,0 +1,4 @@
1%% This file is not generated by configure, because then the provided
2%% pdf files would always appear out-of-date.
3\def\versionemacs{24} % major version of emacs
4\def\year{2015} % latest copyright year