Difference between revisions of "Bug Lists"

From Audacity Wiki
Jump to: navigation, search
(Added link.)
(possibly better wording for link to Using Bugzilla)
Line 82: Line 82:
'''Advice:''' We also have some of that for our bugtracker, if you plan to use it.  [[Using_Bugzilla|The advantages and hazards]] of bugtracking, along with a bit more terminology.   
'''If you plan to use our bugtracker''' you may want to read about the [[Using_Bugzilla|advantages and hazards]] of bugtracking, along with a bit more terminology.   

Revision as of 19:48, 20 April 2011

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 e-mail 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:

Bugs by Priority

Open Bugs   Awaiting Developer Fix
PX   P1 only   P1 bugs prevent any release, including beta.
P1 to P2   P2 only P2 bugs prevent a stable release.
P1 to P3   P3 only P3 bugs must be release noted.
P1 to P4   P4 only P4 and P5 bugs are not release noted.
All Open Bugs   P5 only

Deciding on bug priority is not an exact science, and some of the natural 'rules' conflict with each other.

  • Reproducible crashes and regressions are generally P1.
  • However, reproducible bugs which can't be progressed (e.g. because they are incompatibilities in a driver or operating system beyond our control) will usually be P3 or lower, so they don't needlessly prevent stable releases.
  • Similarly where a bug lacks a ready way to reproduce it there may be pressures to demote it to P3, even if it is a frequently reported crash or regression. One solution to handling a bug demoted for this reason may be to flag or keyword it, or otherwise encourage testers to discover how to reproduce it.

Also a P2 bug in a new feature we can turn off will generally be a reason to turn that feature off in stable releases so that we can get a stable release out.

Workflow when resolving bugs

  • The current workflow is that when a bug has a fix applied 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 and the fix has been committed, QA 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 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.

Some Categories


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