Quality
| Ensuring high quality for open source software is a major challenge. Everyone contributing is a volunteer, so it is not possible to make people follow particular guidelines, only ask that they do.
|
Related article(s):
|
Contents |
Coding Standards
The Coding Standards are a first line of defence.
Comments
We aim to have doxygen comments at the class level so that someone new to the code can understand more rapidly what each class is for. Unusual code is (or should be) commented to make it easier for people new to it to check that it is doing what it should. We also particularly encourage comments where the reason for special case code is not obvious. We've had several cases where such code has been removed in 'tidying up', because it was not relevant to the developer who did so. Some examples of how this can happen:
- Code is only relevant to users with localised versions.
- Code is only relevant to people using a slow network drive.
- Code is needed the first time Audacity runs, when there is no value in the stored config.
- Code supports users who have files in non-standard places, e.g. a path with a space in the name.
- Code addresses some security issue that is relevant when several people share the same machine.
Such code should either be so clear as to why it is there that it doesn't need a comment, or it should have a comment.
Stable and Unstable Releases
Unstable Alpha releases can be produced easily. These will always have known problems and usually new features which are incomplete and under development. Stable releases require more work to release. On Release Checklist we maintain a list of issues that block a stable release, plus for convenience other lower priority bugs to work on after a stable release. In stable releases we generally disable features which are too incomplete, whereas unstable builds will have them present.
Code Reviews
Code reviews using Google's Rietveld interface started to be done in early 2010 after a move from CVS to SVN.
Internal Releases and Nightly Builds
Sometimes the extent and speed of changes being made to development code may mean that one or more release builds are made for internal and developer assessment, but are not officially advertised. Such was the case with the 1.3.6a series of releases during GSoC 2008.
Additionally, nightly or very regular release builds from CVS HEAD have been made available to the developer community for some time. Experimentally, they are being officially advertised as of September 2009 to encourage user feedback in the run-up to Audacity 2.0 (with the obvious stability caveats).
Stable releases will always require at least one "release-candidate" build to be available for assessment in the developer community in the days before actual release.
Plug-in Design
Plug-ins help to reduce the risk of destabilisation of Audacity when there are changes. It will usually be quickly apparent if a plug-in is at fault. Changes are more localised and hence problems easier to track down. An initiative to speed up progress on the modular architecture was started in 2010.
Scripted test
Using the mod-script-pipe plug-in we can now run a scripted test that exercises each of the effects. We intend over time to extend the range of this test script.
Self Test
There is a very primitive 'benchmark' test in the help menu of debug builds. This allows us to perform a set number of edits automatically and verify the results. With batch chains and external scripting we are moving towards more automated testing than we previously had. In addition a new feature for capturing screenshots automatically is available in debug builds and will help with documentation. When it is script-enabled it will help us compare before-and-after results after significant changes.
Stress Testing
One way we stress test is by running Audacity with a small blocksize. This forces Audacity to create many more small files than it would otherwise and helps to test the core system that writes and reads audio from disk.
