Version 2 (coder, 27/03/2012 17:29) → Version 3/6 (coder, 21/12/2012 18:43)

h1. Submitting Enhancements Patches


If you've got a code change that fixes something or adds a feature, we'd love you're welcome to see it. send in a patch. Please use the forums libavg-devel mailing list for this patches 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.

h1. Coding Conventions

Please follow the [[CodingConventions|Coding Conventions]].

h1. Running the Tests

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.

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).

h1. Adding Documentation

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:

<pre><code class="shell">
$ sudo easy_install -U Sphinx

The docs can be rebuilt by calling

<pre><code class="shell">
$ cd libavg
$ ./

Note that documentation is ordered alphabetically. This is not enforced by sphinx, so new entries must be inserted in order.

h1. Checkin Patch Granularity

We want Please submit patches that pertain to one issue at a clear record of checkins, with each checkin taking care of one issue. Changing time. Patches that fix several things at once makes things difficult when we're looking for 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 caused happens, you need to update the patch so it still applies to current svn, and that's a bug, for instance.