Mercurial > emacs
comparison CONTRIBUTE @ 71604:801b0f932405
New file.
author | Nick Roberts <nickrob@snap.net.nz> |
---|---|
date | Tue, 04 Jul 2006 01:16:51 +0000 |
parents | |
children | e4b43205e213 |
comparison
equal
deleted
inserted
replaced
71603:aa82602239d4 | 71604:801b0f932405 |
---|---|
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. |