projects / exim.git / blame
| 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 |