launchpadblog

This past week’s Bug Janitor thread has made it clear that we need better descriptions of what our bug statuses actually mean. While it’s true that many project teams have organically grown their own semantics for Launchpad’s bug statuses, it’s important that there be a large degree of understanding of them between community and Launchpad developers — we want to develop features that make sense, and if you don’t know what we think the statuses means, that becomes a lot harder!

Launchpad currently offers 9 different statuses for bugs. 6 of them model the development workflow from bug report to fix released:

1. New (a.k.a. Nobody Has Looked At Me Yet)

   A bug starts out its life as a New bug. A bug in this status is one which still needs to be evaluated by a triager (essentially, somebody clueful enough about the project to decide whether it’s a bug or not); it is not acknowledged as a bug yet.

   In Bugzilla, this status is called Unconfirmed. In most Trac and Mantis instances this this status is also called New. It is the zero-state of all bugs!
2. Incomplete (Reporter, Give Us More Information!)

   This is the status around which the Bug Janitor’s expiration code works. It is an intermediate stage between New and Confirmed; it means that someone has looked at the bug, attempted to understand or reproduce it, and needs more information to be able to confirm it is in fact a bug.

   Once additional information has been added, the bug is meant to be reviewed and either more information is requested — again, via the Incomplete status — or the bug is marked Confirmed, Invalid or Won’t fix. To review bugs in Ubuntu that are Incomplete which have new information, you would use this report, which uses the “Incomplete (with response)” option in Ubuntu’s advanced bug search form.

   Incomplete is a temporary status: it is intended to be a stepping stone from New to Confirmed that is managed by an active QA team. Bugs aren’t meant to stay here forever, and the Janitor script is meant to enforce that useful semantic: either more information is made available or the bug is closed for lack of information. Of course, the bug can always be reopened or reported again by someone with a better understanding of the symptoms.

   In GNOME’s Bugzilla this is called NEEDSINFO. In fact, in a previous incarnation Launchpad used the same term (Needs Info) for this status, which poorly communicated the fact that it preceded the Confirmed status, and which made it ambiguous: it ended up being used whenever the bug was blocked on missing information. The truth is that the bug can in many situations be blocked on missing information, but Incomplete is meant for the specific gap between New and Confirmed.
3. Confirmed (Oh-Oh He’s Right It’s Broken)

   This means that in fact the bug has been confirmed and exists. QA are meant to mark the bug confirmed only when they have enough information to reproduce the bug or trivially establish that it is in fact something that a developer needs to look at.

   This status is particularly important because from this point onwards, developers will interact much more intensely with the bug; the more information gathered at this point, the better.
4. Triaged (Keep This Bug On The Radar)

   This is an intermediate status that can be used to distinguish community-confirmed bugs from bugs that the official QA team has acknowledged and plans on working on. Many projects don’t need a separate stepping stone and developers can pick bugs directly from Confirmed into In Progress. At this point, we are sure that a) the bug has been reproduced and established b) developers have acknowledged.

   If you are an upstream project and you don’t find the Triaged status useful, please let me know. I want to collect information to determine whether any projects find it useful in order to better adapt the UI to it.
5. In Progress (I Started Working On It!)

   Once all the relevant information has been collected, a developer marks the bug In Progress. This status is practically always set by the developer himself, indicating that he has already started the analysis and coding work towards fixing it.

   This is an exciting status and in general, bugs should not last too long (or get stuck) here. If they get stuck here, chances are that the developer has given up on the bug (in which case it should be moved back to Triaged or Confirmed), or that he has started and stopped work on it (in which case he needs help to get it unblocked).
6. Fix Committed (Please Test My Fix)

   This is a special status that indicates that the developer has produced a working fix and has committed it to revision control.
   In a way this is a status geared towards projects that use RCS extensively, but generally speaking OSS projects do use RCS and do commit bug fixes to revision control as part of the bug fix process.

   The qualified definition for this status is that while a fix does exist (and in projects with code review, that it has been accepted by the official project team) it has not been made available in a version released to the general public.

   For distribution packages, this status is intended to communicate that the developer has produced a fix in a location other than the official Ubuntu archive; in Ubuntu, for instance, in a bzr branch of the package, or as an upload in a PPA or ubuntu-proposed.
7. Fix Released (This Revolution Is Over!)

   This status is meant to communicate that the bug fix has been made available in a released form to the general public. The key meaning of this status is public availability; end-users can expect to download or access an updated version of the software that contains the change.

   In the case of Ubuntu, bugs are automatically marked Fix Released when sources are uploaded to the official Ubuntu archive. This is an approximation, given that the source may fail to compile, but it is a simpler workflow which works well.

There are two additional statuses that are used to capture reports that have been rejected:

8. Invalid: This status is synonymous with “Not a valid bug”. There are many reasons a bug might not be valid: if it was deemed to be user error, or if there was not enough information to establish whether it was a bug or not. The reporter might be asking a question, testing (or joking). The actual project it was reported against might have been dismantled and abandoned. Invalid is meant to catch all the cases where the reporter’s request is best handled in a different form, or not at all.
9. Won’t Fix: This status is only meant to be used by official project members. It is a statement that confirms that a problem exists, but that no work will be done towards fixing it. Perhaps it’s a controversial issue upon which an official decision has been issued, or it’s something that is better addressed in a different way, or fixed in another software component. It is often used in association with release targeting to specify that a bug will not be fixed in that release.

From the above, you will notice that the bug workflow in Launchpad is pretty linear, traversing from New to Fix Released (or one of the two Rejected statuses). Of course, this traversal can take a long time depending on the availability of information and resources, but there are no major forks in line.

Access Restrictions

For the most part, Launchpad is liberal as to who can set bugs to a status; we would rather allow people to help garden the bug statuses than force them to ask permission to do so. There are two statuses, however, which are restricted to the project’s bug contacts and registrant: Won’t Fix, and Triaged.

• Won’t Fix is restricted for a very specific reason: it is intended to represent an official denial, and therefore should really only be pronounced by a member of the project.
• Triaged is restricted because it intends to capture confirmation by an accredited QA person who has verified that enough information has now been gathered about the issue that it can go straight into a developer’s work queue.

Project registrants can set up bug contacts by using the “Change bug contact” link on their bugs.launchpad.net project page. Bug contacts get notifications of all bug changes in a project; if that’s overwhelming, you can use our X-Launchpad header family to filter things in your mail client.

Thanks

This is my first posting on bug statuses. My next posting will talk about concrete situations in the bug tracker, focusing on corner cases (such as “what do I do when this bug report has already been fixed by an unrelated change?”); help me out by adding comments that describe situations which you are unsure of and I’ll consider them in my article. Thanks!

This entry was posted by kiko on Tuesday, September 25th, 2007 at 9:04 pm and is filed under Bug Tracking, General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.