Patches
Version 4 (michael.lotz_iart, 26/04/2013 22:42)
| 1 | 3 | coder | h1. Submitting Enhancements |
|---|---|---|---|
| 2 | 1 | admin | |
| 3 | 1 | admin | {{>toc}} |
| 4 | 1 | admin | |
| 5 | 4 | michael.lotz_iart | If you've got a code change that fixes something or adds a feature, we'd love to see it. Please use the forums for this and work off current svn. Small changes are probably best sent as patch files; for larger ones, we can pull from your git/Mercurial repository - or you can use patches as well. |
| 6 | 1 | admin | |
| 7 | 1 | admin | h1. Coding Conventions |
| 8 | 1 | admin | |
| 9 | 1 | admin | Please follow the [[CodingConventions|Coding Conventions]]. |
| 10 | 1 | admin | |
| 11 | 1 | admin | h1. Running the Tests |
| 12 | 1 | admin | |
| 13 | 2 | coder | libavg contains a number of tests that run automatically and alert the user if anything doesn't work as expected. The tests are actually pretty comprehensive and find a lot of issues that would otherwise slip through the cracks. To run the tests, do a @make check@. The tests that have to do with images will save images for the failing tests in a @resultimages/@ subdirectory. For each failed test, there will be three images: the current result, the expected result, and a diference image - giving you a good clue about what's happening. |
| 14 | 1 | admin | |
| 15 | 2 | coder | If you add a feature, please add a test (or several) that make sure the feature works. If you fix a bug, then there should often have been a test that finds the bug ;-), and it's appreciated if you add an appropriate test as well. (That also makes the bug reproducible, thus making your fix more likely to be applied). |
| 16 | 1 | admin | |
| 17 | 1 | admin | h1. Adding Documentation |
| 18 | 1 | admin | |
| 19 | 1 | admin | If the patch changes the interface of libavg, we need an update to the reference documentation in libavg/sphinxdoc. To build the documentation, you need "Sphinx":http://sphinx.pocoo.org/ installed: |
| 20 | 1 | admin | |
| 21 | 1 | admin | <pre><code class="shell"> |
| 22 | 1 | admin | $ sudo easy_install -U Sphinx |
| 23 | 1 | admin | </code></pre> |
| 24 | 1 | admin | |
| 25 | 1 | admin | The docs can be rebuilt by calling |
| 26 | 1 | admin | |
| 27 | 1 | admin | <pre><code class="shell"> |
| 28 | 1 | admin | $ cd libavg |
| 29 | 1 | admin | $ ./makedocs.sh |
| 30 | 1 | admin | </code></pre> |
| 31 | 1 | admin | |
| 32 | 2 | coder | Note that documentation is ordered alphabetically. This is not enforced by sphinx, so new entries must be inserted in order. |
| 33 | 1 | admin | |
| 34 | 3 | coder | h1. Checkin Granularity |
| 35 | 1 | admin | |
| 36 | 3 | coder | We want a clear record of checkins, with each checkin taking care of one issue. Changing several things at once makes things difficult when we're looking for the code change that caused a bug, for instance. |