| 1 | CONTRIBUTING TO EXIM |
| 2 | ==================== |
| 3 | |
| 4 | Exim is an open-source project licensed under the GNU General Public License. |
| 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 |