Patches

Version 3 (coder, 21/12/2012 18:43)

1 3 coder
h1. Submitting Enhancements
2 1 admin
3 1 admin
{{>toc}}
4 1 admin
5 3 coder
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/Mercury 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.