GitHub Pull Requests
- If you wish to submit a pull request (other than for some simple text change) it's usually best to discuss this with us on audacity-devel.
- Translation changes must be submitted by subscribing to the audacity-translation list, even if only changing one or two words.
We have these possible labels:
- thanks. will pull - usually for fixes that are clearly what we want, where the main reason we are not pulling straight away is that we are in freeze.
- nice idea - We like the idea. This is neither positive nor negative about the implementation of the idea. We might not have reviewed or tried out the implementation yet.
- who can test? - This PR is not being progressed for want of someone to try it out, e.g different platform to most developers, or it is using non standard hardware. Talk with us!
- do we want this? - Do we like the sound of this feature as described? If our answer is yes, request becomes 'nice idea'. If no, thanks but no thanks.
- lib-src or nyquist - This PR is about 'issues' with upstream code. Closing these pull requests generally requires communication upstream. Nyquist is easiest as upstream is in-house. Other ones likely will take longer. It's why we don't fix warnings on lib-src code.
We have two milestones:
This isn't a milestone. It's a way to tell people making any decent sized pull requests to please come over talk with us at the audacity-devel email list. If you just rely on the GitHub pull request messages, you may find we ignore or close the pull request for what does not seem to you to be a good reason. Please come and talk.There is a bit more on our wiki about how we use these pull requests.
This isn't a milestone. It's a way to tell translators how we deal with GitHub pull requests. Translators should subscribe to audacity translators email list. MOST changes will be taken from .po files posted there and most discussions will happen there (not here). If you just rely on the GitHub pull request messages, you may find we ignore or close the pull request for what does not seem to you to be a good reason.The translators list is also the right place for most translation discussion.
- Don't pay too much attention to the tables below. They are not automatically updated.
On the way to being closed
Open requests that we are probably going to close soon, or at least we hope so. That could be close REJECT or close ACCEPT.
|75||Use noinst_SCRIPTS for toplevel audacity script||0-wiz-0||James hasn't much of a clue what this is about. It's short, and it looks like it should be a quick decision for someone who does know.|
|112||build: rework everything to use wxString instead of pointer-to-wxChar||jenglh||Fixes compilation on OpenSUSE; +1 on that from ThomasFeher. Seems to make sense, but the PR needs more work. Paul reviewed and saw significant problems.|
Closed but 'Nice Idea'
Closed pull requests that we want to look at again later. Possibly closed because either it or we are not ready for that pull request. These are pull requests worth looking at again, even though closed.
|163||OpenMP TrackArtist::DrawSpectrum 3 times faster.||Darrell Walisser||Paul reviewed and was bothered mainly by changes which impact his as yet unmerged FishEye code. Hoping/expecting a resubmit.|
|135||Create a hidden configuration option to disable the save prompt on exit #135||Bracketcc||The actual pull request is enormous, so something has gone wrong somewhere, and it wasn't pulled. Maybe look at #134 for the basic idea.|
|142||Parameter loading for batch EQ||Wave Motion||Like the feature, but implementation not completed.|
|130||'build fixes'||Max Kellermann||Part of fix to Add consts in FFmpeg cherry picked by Walisser and Paul. Long somewhat heated PR thread.|
|49||Run chain from command line||Cory Cook||Possibly an OK idea, but better done through using some of this code in scripting? Rejected in the end.|