|If you've made a change to Audacity that you'd like to share with us, please send us a patch to look at! A patch is a file listing the line-by-line differences between one set of files and another, in this case, between your files and ours in SVN.
Which version of Audacity should I patch?
Always patch against SVN HEAD if at all possible. If your patch is a tiny bug fix with minimal code lines changed, you could conceivably submit a patch against the Audacity stable branch. Patch files are designed to be "redundant", meaning that if the source you are using is out of date, the patch "might" still work. The current command-line usage to checkout stable is:
|svn checkout http://audacity.googlecode.com/svn/audacity-src/branches/AUDACITY_1_2 audacity-stable-read-only|
If your patch adds a new feature, or is an extensive change, please submit your patch against the unstable development branch of Audacity, or ideally against SVN HEAD. The command-line usage to checkout HEAD is:
|svn checkout http://audacity.googlecode.com/svn/audacity-src/trunk/ audacity-read-only|
How to create a patch
Inside of an Audacity SVN directory, just type:
|svn diff > patchfile|
Alternatively, download a fresh copy of Audacity, make two copies of the directory, and then run recursive diff from the command line as follows:
|diff -r -u audacity audacity-patched > patchfile|
The "-u" switch produces a file in "unified diff format" which is easier to read and includes proper context information.
If you use TortoiseSVN, it has a handy right-click context menu item . Right-click over the root folder of the tree to make sure all relevant files are included in the patch. You can uncheck any that are not relevant in the Create Patch dialogue.
Where should I send it?
The best way to interact with us is to subscribe to the Audacity-Devel mailing list. Then send us an e-mail including the patch as a plain text attachment. We all get a lot of e-mail, so:
- a good subject title prefaced by [PATCH], such as "[PATCH] Fix for bug 1939 Toolbars Crash"
- a one-line summary of the purpose of the patch
- a bullet point summary of what it changes
will help enormously.
If you receive an automated response that the patch is being held for moderation because it is too large, be patient, we'll let it through. If the patch is too large to attach to an e-mail, please upload it to a web site and give us a link to where it can be downloaded, or tell us the patch is too large and we'll make other arrangements to look at it.
If you are already subscribed to Audacity-Devel and have an account on our Bugzilla, it's fine too to attach a patch to an existing bug report along with your comment about the patch.
If you prefer not to subscribe to a mailing list (for example, if you have a one-off patch for an obvious mistake in our code that you have verified fixes the problem), an alternative is to e-mail our feedback address with your patch.
Why are you ignoring me?
The Audacity developers don't mean to be rude. We will try to respond quickly in full, or failing that, acknowledge your e-mail and let you know when we hope to respond. Some of the reasons we might not accept your patch or respond to your e-mail immediately include:
- You didn't patch the proper version of Audacity. If you send us a patch for an obsolete version of Audacity, not only will it be difficult for us to port your patch to the latest code, but it may not even be relevant.
- Your patch is very long - it might take us a while to sort through it and figure out what you did. We welcome contributions, but we like to understand what they do.
- We're worried that the patch might have unintended consequences - the patch might work great for you, but we've been working with this code for a long time, and we might be anticipating a potential problem that might not be immediately obvious to you.
- We're busy. We all work on this in our spare time. If for example you contact us around the time of a new release, it may be difficult to respond promptly. If you don't see anything wrong with your patch and you haven't heard anything after a week, please send a reminder e-mail to -devel list using the same subject as the original e-mail. If we're still ignoring you a week later, remind us again! We'll at least try to give you some idea why we haven't responded yet. As soon as we can, we will review your patch and let you know if we can commit it.