Bug Lists

From Audacity Wiki
Jump to: navigation, search
The Audacity Team track bugs and agreed enhancement issues on our Bugzilla. This page is a list of useful Bugzilla links for Developer/Quality Assurance use.
If you are a member of the public reporting a bug, please read Reporting Bugs and then send an email to our feedback address. Suggestions for new or improved features are also welcome at that address.


Quick Links:


Tip: For easy access, bookmark any links in these bug lists!


Tip: If you go to our bugzilla, clicking on the Audacity Icon at top left takes you to a summary table of open bugs. Clicking on the numbers in that table takes you to those bugs.



Latest Changes for:

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

Bugs by Priority

Open Bugs   Awaiting Developer Fix
PX   P0/P1   P0 bugs are bugs so bad they seriously impede development. Preventing recording working, or disabling mouse drags or more prosaically a build breaker would be P0. P0's affect the development team and impede testing by the QA team.
P0 to P2   P2 only P1 bugs prevent a new release. These will include most reproducible crashes, most things that cause data loss and most regressions. P1's would affect large numbers of users, if released.
P1 to P3   P3 only P2 bugs still open when the release process starts, can be fixed or not at the discretion of the Release Manager. Unfixed bugs must be release noted.
P1 to P4   P4 only P3 bugs are lower severity bugs which must still be release noted.
All Open Bugs   P5 only P4 and P5 bugs are not release noted. Many of these may be "enhancement issues".

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


Bug fixing at release time: The Release Manager can decide to fix or not fix any bug for a release. Almost any P1 bug will be fixed, unless currently available fixes are deemed a stability risk, so requiring demotion to P2. Most P2 bugs open at release time will be accepted in a release, though the Release Manager may decide that some P2's or even P3's related to other improvements in a release should be fixed.


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.


If you plan to use our bugtracker you may want to read about the advantages and hazards of bugtracking, along with a bit more terminology.

Residuals

Tracking "Residual" bugs after a fix can be tricky, but I think that the guideline should be:

  1. If the residual is part of the original bug description, then it should initially be treated as the same bug (subject to "3" and "4")
  2. If the residual is due to an incomplete fix of the code that causes the described bug, then it should initially be treated as the same bug (subject to "3" and "4")
  3. If the description of the residual differs from the original bug description, then it should be treated as a new bug.
  4. If the residual is due to an error in code that is unrelated to the original bug, then it should be treated as a new bug, even if the symptoms have similarities.

Item 4 is likely to be difficult to determine for non-developers, but the developer that fixes the bug will normally be able to advise. In some cases, "4" may not initially be apparent to the developer, but if it becomes apparent at a later date, the residual may be migrated to a new bug.

If there is doubt whether a "residual" is part of the original bug or not, it should be discussed on the QA list in the first instance. If it boils down to a question of code, then it may be migrated to the devel list.

This approach helps avoid long, meandering bug threads which can otherwise hinder fixes.

  • As a rider, if we do choose to include a residual with new steps in the same bug, use
 *** STEPS UPDATED ***

In the bug comments. This saves people new to the bug reading all the way back to the start and it makes it clear the bug is open for a residual.

Some Categories


Reports

Not strictly bug lists...

One Level

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.
  • Bugs and Issues. This pair of tables splits the actual real bugs from issues (enhancements, summary, review items). We also have this table for closed bugs.
  • 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