Patches

Version 1 (admin, 20/03/2012 14:39)

1 1 admin
h1. Submitting Patches
2 1 admin
3 1 admin
{{>toc}}
4 1 admin
5 1 admin
If you've got a code change that fixes something or adds a feature, you're welcome to send in a patch. Please use the libavg-devel mailing list for patches and work off current svn.
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 1 admin
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 diff image - giving you a good clue about what's happening.
14 1 admin
15 1 admin
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 habe 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 1 admin
Note that documentation is ordered alphabetically. This is not enforced by the sphinx, so new entries must be inserted in order.
33 1 admin
34 1 admin
h1. Patch Granularity
35 1 admin
36 1 admin
Please submit patches that pertain to one issue at a time. Patches that fix several things at once are a hassle to apply in pieces. Also, small patches increase the chance that they'll be applied quickly, decreasing the change that the code will change while work on the patch is still progressing. (If that happens, you need to update the patch so it still applies to current svn, and that's a hassle.)