Commit | Line | Data |
---|---|---|
2daddfb8 PP |
1 | CONTRIBUTING TO EXIM |
2 | ==================== | |
3 | ||
293ae364 | 4 | Exim is an open-source project licensed under the GNU General Public License. |
2daddfb8 PP |
5 | At time of writing, all the developers work on Exim on a volunteer basis. |
6 | We welcome patches and contributions. There is no copyright assignment | |
7 | policy; if you offer a patch, it is assumed to be under the GPL, of whichever | |
8 | version the main developers see fit to use. | |
9 | ||
10 | Mistakes or inadequacies in the documentation are treated as bugs. The main | |
11 | documentation is called "The Exim Specification" for a reason. So if you | |
12 | can't code there are still places where your help will be very appreciated. | |
13 | ||
14 | General discussion, requests for help, and initial "is this a bug?" questions | |
15 | go to <exim-users@exim.org>. Many suspected bugs turn out to not be bugs, so | |
16 | asking first is appreciated. | |
17 | ||
18 | Our main website is at http://www.exim.org/ and contains links to our wiki, | |
19 | where many frequent setups are walked through. You will also find our | |
20 | bug-tracking system linked there. | |
21 | ||
22 | Development takes place in part on exim-users, when bugs or missing features | |
23 | are spotted based on feedback from people actually using the product. In | |
24 | large part, discussion takes place on <exim-dev@exim.org>. While you can use | |
25 | the bug-tracking system, everyone working on Exim, a mail transfer agent, is | |
26 | comfortable dealing with just email too, so you can use whichever you're most | |
27 | comfortable with. | |
28 | ||
29 | If you have an idea for a new feature, please do raise it on exim-users first. | |
30 | ||
31 | Our code is maintained in a Git repository. The master repository, together | |
32 | with some others, can be found on http://git.exim.org/ and we welcome patches, | |
33 | whether of documentation or of code. If you have a request for a new feature | |
34 | and can accompany it with working code, then it stands a much greater chance | |
35 | of being incorporated in a timely manner. | |
36 | ||
37 | If you're planning on working on a major new feature or redesign, please do | |
38 | talk to us first. | |
39 | ||
40 | We do not have a formal code-review process, but posted patches are subject to | |
41 | being reworked before being pulled in, or requests for modification made; | |
42 | we're a small enough pool of developers that we rely on the good judgement and | |
43 | discretion of the committer rather than formal process. | |
44 | ||
45 | We prefer new features to be accompanied by documentation patches, but if no | |
46 | new documentation is provided, we can write it and, in the process, perhaps | |
47 | uncover issues to work over with you. Note that the PDF form of the | |
48 | documentation is faster to build than the TXT form. | |
49 | ||
50 | We do have a test harness and appreciate it if new features can be accompanied | |
51 | by new tests; if this is awkward for you, please do include sufficient | |
52 | description to allow someone else to write the test. | |
53 | ||
54 | ||
55 | -The Exim Maintainers | |
56 | July 7th, 2010 |