Of Bugs and Statuses

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:

  1. 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.
  2. 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!

8 Responses to “Of Bugs and Statuses”

  1. b-initials Says:

    Bug statuses in Launchpad….

    I have been following the discussions on ubuntu-devel, -devel-discuss and -launchpad-users mailing lists regarding the status of Ubuntu bugs. There are many different discussion threads, some of them cross-posted, so it is a little difficult to give al…

  2. santosh Says:

    actually I wanted the clear life cycle of the bug in simple form.

  3. Michal Says:

    Once a bug is closed, what status do you use? Does Fix Released mean closed?

  4. Daniel Says:

    I couldn’t understand some parts of this article gs and Statuses at Launchpad blog, but I guess I just need to check some more resources regarding this, because it sounds interesting.

  5. kiko Says:

    It depends on what you mean by “a bug is closed”. If you mean the fix for the bug has been committed to revision control, use Fix Committed. If you mean that the fix for the bug is available to end-users, use Fix Released.

    I guess that’s ambiguous if you release to your end-users using revision control only, but which crazy project actually does that?

  6. Ralph Corderoy Says:

    Could you please clarify who can set a bug to Confirmed? The description says “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.” but later it says “community-confirmed bugs” suggesting non-QA can confirm a bug.

    And given the definition of Confirmed is “Oh-Oh He’s Right It’s Broken”, can a bug be set to that from the off because it’s all too clear it’s a bug.

    https://bugs.launchpad.net/bugs/208837 is an example if you need a case in point. 🙂

  7. solrize Says:

    I saw “triaged” all the time but never understood what it meant. What I’m looking for is a way of closing a bug without either rejecting it or fixing it. E.g. bug A is a genuine bug and discussion happens on its ticket. Similarly with bug B, which is different from bug A. I work on a fix that’s primarily for bug B but is actually a unified fix for both bugs. So I want to close bug A and refer viewers to bug B where discussion of the fix is taking place. I don’t want to mark A as duplicate since it’s really a different bug and “duplicate” removes it from search (but there’s still useful discussion there). I don’t want to mark it as “fix committed” because the fix is still in progress. The idea is to merge two complex bugs and “duplicate” refers to a simpler situation where the same bug has gotten reported more than once.

  8. Alex Says:

    I personally (in my various projects on Launchpad) have never found a use for the ‘triaged’ status. The usage of the word is quite uncommon and its meaning a little obscure. Personally, I would vote to get rid of it.

Leave a Reply