|
71604
|
1
|
|
|
2 Contributing to Emacs
|
|
|
3
|
|
|
4 Emacs is a collaborative project and one which wants to encourage new
|
|
|
5 development. You may wish to fix Emacs bugs, improve testing, port
|
|
|
6 Emacs to a new platform, update documentation, add new Emacs features,
|
|
|
7 and the like. To help with this, there is a lot of documentation
|
|
|
8 available. In addition to the user guide and Lisp Reference Manual in
|
|
|
9 the Emacs distribution, the Emacs web pages also contain much
|
|
|
10 information.
|
|
|
11
|
|
|
12 You may also want to submit your change so that can be considered for
|
|
|
13 conclusion in a future version of Emacs (see below).
|
|
|
14
|
|
|
15 If you don't feel up to hacking Emacs, there are still plenty of ways to
|
|
|
16 help! You can answer questions on the mailing lists, write
|
|
|
17 documentation, find bugs, create a Emacs related website (contribute to
|
|
|
18 the official Emacs web site), or create a Emacs related software
|
|
|
19 package. We welcome all of the above and feel free to ask on the Emacs
|
|
|
20 mailing lists if you are looking for feedback or for people to review a
|
|
|
21 work in progress.
|
|
|
22
|
|
|
23 Ref: http://www.gnu.org/software/emacs/
|
|
|
24
|
|
|
25 Finally, there are certain legal requirements and style issues which
|
|
|
26 all contributors need to be aware of.
|
|
|
27
|
|
|
28 o Coding Standards
|
|
|
29
|
|
|
30 All contributions must conform to the GNU Coding Standard.
|
|
|
31 Submissions which do not conform to the standards will be
|
|
|
32 returned with a request to reformat the changes.
|
|
|
33
|
|
|
34 Emacs has certain additional coding requirements.
|
|
|
35
|
|
|
36 Ref: http://www.gnu.org/prep/standards_toc.html
|
|
|
37
|
|
|
38
|
|
|
39 o Copyright Assignment
|
|
|
40
|
|
|
41 Before we can accept code contributions from you, we need a
|
|
|
42 copyright assignment form filled out and filed with the FSF.
|
|
|
43
|
|
|
44 See some documentation by the FSF for details and contact us
|
|
|
45 via the Emacs mailing list to obtain the relevant
|
|
|
46 forms.
|
|
|
47
|
|
|
48 Small changes can be accepted without a copyright assignment
|
|
|
49 form on file.
|
|
|
50
|
|
|
51 Ref: http://www.gnu.org/prep/maintain.html#SEC6
|
|
|
52
|
|
|
53
|
|
|
54 o Getting the Source Code
|
|
|
55
|
|
|
56 The latest version of Emacs can be downloaded using CVS or Arch
|
|
|
57 from the Savannah web site. It is important that you submit
|
|
|
58 your patch using this version, as any bug in a released version
|
|
|
59 of Emacs may already be fixed. It also makes it easier for
|
|
|
60 others to test your patch,
|
|
|
61
|
|
|
62 Ref: http://savannah.gnu.org/projects/emacs
|
|
|
63
|
|
|
64
|
|
|
65 o Submitting Patches
|
|
|
66
|
|
|
67 Every patch must have several pieces of information before we
|
|
|
68 can properly evaluate it.
|
|
|
69
|
|
|
70 For bug fixes, a description of the bug and how your patch fixes
|
|
|
71 this bug.
|
|
|
72
|
|
|
73 For new features, a description of the feature and your
|
|
|
74 implementation.
|
|
|
75
|
|
|
76 A ChangeLog entry as plaintext (separate from the patch); see
|
|
|
77 the various ChangeLog files for format and content. Note that,
|
|
|
78 unlike some other projects, we do require ChangeLogs also for
|
|
|
79 documentation (i.e., .texi files).
|
|
|
80
|
|
|
81 The patch itself. If you are accessing the CVS repository use
|
|
|
82 "cvs update; cvs diff -cp"; else, use "diff -cp OLD NEW" or
|
|
|
83 "diff -up OLD NEW". If your version of diff does not support
|
|
|
84 these options, then get the latest version of GNU diff.
|
|
|
85
|
|
|
86 We accept patches as plain text (preferred for the compilers
|
|
|
87 themselves), MIME attachments (preferred for the web pages),
|
|
|
88 or as uuencoded gzipped text.
|
|
|
89
|
|
|
90 When you have all these pieces, bundle them up in a mail message
|
|
|
91 and send it to emacs-pretest-bug@gnu.org or emacs-devel@gnu.org.
|
|
|
92 All patches and related discussion should be sent to the
|
|
|
93 emacs-pretest-bug mailinglist.
|
|
|
94
|
|
|
95
|
|
|
96 o Please read your patch before submitting it.
|
|
|
97
|
|
|
98 A patch containing several unrelated changes or
|
|
|
99 arbitrary reformats will be returned with a request
|
|
|
100 to re-formatting / split it.
|
|
|
101
|
|
|
102
|
|
|
103 o Supplemental information for Emacs Developers:
|
|
|
104
|
|
|
105 If you wish to contribute to Emacs on a regular basis then
|
|
|
106 you may be given write access to the CVS repository.
|
|
|
107
|
|
|
108 Discussion about Emacs development takes place on
|
|
|
109 emacs-devel@gnu.org.
|
|
|
110
|
|
|
111 Think carefully about whether your change requires updating the
|
|
|
112 documentation. If it does, you can either do this yourself or
|
|
|
113 add an item to the NEWS file.
|
|
|
114
|
|
|
115 The best way to understand Emacs Internals is to read the code
|
|
|
116 but there is also a node "GNU Emacs Internals" in the Appendix
|
|
|
117 of the Emacs Lisp Reference Manual that may help.
|
|
|
118
|
|
|
119 The file DEBUG describes how to debug Emacs.
|
|
|
120
|
|
|
121 Avoid using `defadvice' or `eval-after-load' for lisp
|
|
|
122 code to be included in Emacs.
|
