Bug Lists

Quick Links:
 * Table of issues awaiting fix or review by Priority and Bug Type (also available from the Audacity icon on Bugzilla)
 * Latest alpha development builds of Audacity
 * [mailto:gale@audacityteam.org?subject=Bugzilla_account Ask for a Bugzilla account] (for experienced C++ developers or seasoned bug watchers who want to actively fix or test bugs)
 * How to submit patches to our feedback address or developers' mailing list
 * audacity-devel developers' mailing list information

Latest Changes for:

 * Open Audacity issues (excluding "Patches awaiting triage" product)


 * All open issues (including "Patches awaiting triage" product)


 * All open issues that have Patches attached


 * All open issues that have Patches attached, that are agreed on and ready for developer review ("patch_ready")


 * Manual bugs (issues with the written documentation, not infrastructure or coding issues about serving it) - Note: links to MediaWiki:Sidebar, ToDo, Welcome For Editors and Help:Translating are NOT bugs.
 * Manual P1 bugs
 * Manual P2 bugs

Assessing bug priority to maintain Quality Requirement
From the start of the 2.0 series, Audacity removed the former distinction between "stable" and "beta" releases in favour of single series of high-quality releases suitable for all users.

Accordingly, the former meaning of a P2 bug as one that "blocks a stable but not a beta release" was discarded. Bugs that would previously have been rated as P2 are now P1. Our Quality Requirement for single releases is as follows.


 * Never less good overall than the standard set by 2.0.0 - only trivial regressions are likely to be tolerated in a release.
 * Not necessarily laden with new or improved features - in a few releases the main focus may be on housekeeping and bug-fixing, while in most there will be a balance between features and fixes. Major new features will be isolated in plug-ins, and not included in a release until any major shortcomings have been ironed out.
 * Not necessarily "fully stable" - perceived stability, like ratings of bugs, is not an exact science. We want to release more regularly than was the case during the 1.3 Beta series, so it is possible that some crash bugs could be demoted from P1 release blocker status if their impact is minor, or if they only occur in rare or non-reproducible scenarios. Driver or operating system incompatibilities beyond our control will normally be "WONTFIX" P3 release-noted.

Workflow when resolving bugs

 * When a bug has a fix committed by a developer, the developer should move the bug status to DEVEL - FIX MADE. This means the bug is still OPEN. Then QA should test it, ideally on all three platforms. If QA are happy with the result, they move the bug status to RESOLVED - FIXED. That means the bug is closed. It will not be visible in searches except when searching for       Fixed.


 * It is suggested the only case where a developer should change bug status to RESOLVED - FIXED should be for bugs P3 and below where a logic error was to blame which does not appear to have possible platform or machine dependencies, AND where this fix has been committed.

Some Categories

 * Fixed
 * Fix made by developer, not yet resolved by QA
 * Moonphase or Heisenbug
 * Enhancement Requests
 * Nyquist
 * Platform Specific
 * All awaiting fix or review by developer

Reports
Not strictly bug lists...

One Level

 * Number of P1's to P5's

Two Levels

 * Bug Type and Priority. This is showing open bugs.  It is possibly the best table for getting an overview of the kinds of live bugs we have.
 * Status and Priority. This is showing both open and closed bugs.  It shows, for example, that we tend to close a higher proportion of high priority bugs than lower priority bugs.
 * Status and Bug Type. This is showing open and closed bugs.  It shows, for example, that summary issues tend to stay open.

Three Levels

 * 3-Levels of Bug Counts