Bug statuses are a reflection of the current state of a bug report.

The status of a bug report can be modified by clicking on the current status in the yellow line, which will reveal a sub menu. You can then set a new status in the drop down box.

Below is a list of bug statuses, their meaning and when to use them:

  • New:

    • Bugs are submitted with this status,
    • They sometimes lack information and

    • All of them should be untriaged
  • Incomplete:

    • If you have to ask the reporter questions, set the bug to Incomplete

    • Ask the submitter to provide any necessary information in a comment, and make sure you subscribe yourself to the bug report so you will get any updates to the bug via e-mail.
    • In the event that a bug has been in the "Incomplete" state for more than 4 weeks, meaning it has not received a response to a request for more information, please send a gentle reminder with something like:

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

If, after an additional 2 weeks, the reporter still hasn't responded and there is no way someone can work with the bug, the bug status should be changed to "Invalid" with a comment similar to:

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

  • Opinion:

    • The status 'opinion' means there is a difference of opinion around a particular bug and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed. The idea is that bugs can be marked closed, so developers aren't wasting time on them, but discussion can still be on-going.
    • This status 'opinion' is considered an experiment, and will be closely monitored over the next 3 months starting from July 7th, 2010.
  • Invalid:

    • This status should be used when the bug report does not contain adequate information to determine whether or not it is a bug even if it is resolved for the reporter
    • This should also be used if the reported problem is not a bug at all, but for example user error
    • It should be used conservatively as bugs marked as Invalid no longer show up in default searches
    • Be sure to triple-check a bug before you invalidate it
  • Expired

    • This status is similar to Invalid, but is meant specifically for bugs that have been Incomplete for too long. (See above.)
    • This status is only able to be set by using launchpadlib or the email interface.
    • Like Invalid bugs, Expired bugs do not show up in default searches.
  • Confirmed:

    • Another reporter has experienced the same bug, this can come in the form of a duplicate bug or a bug comment
    • Confirmed bugs require confirmation from someone other than the original reporter

    • This helps ensure that the bug is applicable to Linaro in general, and not a problem with the reporter's system, therefore...
    • Please don't confirm your own bugs!
  • Triaged:

    • A member of Linaro believes that the report describes a genuine bug in enough detail that a developer could start working on a fix. (also see tip below)

    • Use this when you are confident that it should be looked at by a developer and has enough information

    • While not a requirement a bug's Linaro task status will be Triaged before any upstream forwarding occurs
  • In Progress:

    • If you are working on fixing a bug, set it to In Progress so people know what's going on

    • In Progress bugs should be assigned to the person working on them

  • Fix Committed:

    • Linaro bug task: the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla)
      • Fix Committed is also used when an updated package exists in a -proposed repository i.e. hardy-proposed

      • Fix Committed is not to be used when a patch is attached to a bug

    • Upstream bug task: the fix is in CVS/SVN/bzr or committed to some place
  • Fix Released:

    • Linaro bug task: a fix was uploaded to an official repository
      • N.B. This does not include -proposed i.e. hardy-proposed

      • Please don't hesitate to add a changelog as a comment, so people know in which package version a bug was fixed
      • If a bug is fixed in the current development release, it is Fix Released. If the bug also needs to be fixed in a stable release, use the "Target to release" link to nominate it for that release.

    • Upstream bug task: a release tarball was announced and is publicly available
  • Won't Fix:

    • This status is sometimes used when the bug fix is too controversial
    • It is most often used for bugs with a release target that will not be fixed in that particular release but may be fixed later
    • It may also be used for feature requests that the developers do not want to implement

/!\ the following status changes are restricted to members of Linaro or package maintainers:

  • moving to Triaged, or WONTFIX
  • moving from WONTFIX

  • targeting to a specific Linaro release

Frequently Asked Questions

If you have a question, please feel free to add it here without an answer. A Linaro member will add the answer later.

  • What is the appropriate status if the bug's reporter later says the bug no longer exists but the related changelog does not note a fix?
    • See the first point under "Invalid", the bug does not have sufficient information.
  • What should a triager do if there is consensus among users and developers that an issue is valid but there is no good solution?

    • Keep the bug open with a status of "Wishlist" or "Triaged", depending on the severity.
  • Should the bug reporter reset the bug status to "New" if providing more information to an "Incomplete" bug?
    • Yes.
  • When converting a question to a bug, can the bug status immediately be set to "Confirmed" if comments in the question indicate that multiple users experience the bug?
    • Make a judgment call: as long as more than one person experiences the bug, the proper status is "Confirmed".

  • What should a triager do if a bug needs more information, including steps to reproduce, but the original reporter is not available to provide it?
    • Mark the bug as Invalid with a comment that the reporter should provide the information and reopen the bug by resetting its status to 'New'.

internal/archive/Process/Bugs/Status (last modified 2013-08-28 13:27:01)