Version 5 (Richy, 31/05/2014 11:53)

1 5 Richy
2 5 Richy
[[Contribute| Look here instead]]
3 5 Richy
4 3 coder
h1. Submitting Enhancements
5 1 admin
6 1 admin
7 1 admin
8 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.
9 1 admin
10 1 admin
h1. Coding Conventions
11 1 admin
12 1 admin
Please follow the [[CodingConventions|Coding Conventions]].
13 1 admin
14 1 admin
h1. Running the Tests
15 1 admin
16 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.
17 1 admin
18 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).
19 1 admin
20 1 admin
h1. Adding Documentation
21 1 admin
22 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": installed:
23 1 admin
24 1 admin
<pre><code class="shell">
25 1 admin
$ sudo easy_install -U Sphinx
26 1 admin
27 1 admin
28 1 admin
The docs can be rebuilt by calling
29 1 admin
30 1 admin
<pre><code class="shell">
31 1 admin
$ cd libavg
32 1 admin
$ ./
33 1 admin
34 1 admin
35 2 coder
Note that documentation is ordered alphabetically. This is not enforced by sphinx, so new entries must be inserted in order.
36 1 admin
37 3 coder
h1. Checkin Granularity
38 1 admin
39 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.