Bug statuses

Differences between revisions 1 and 77 (spanning 76 versions)
Revision 1 as of 2007-07-17 23:46:31
Size: 2618
Editor: c-24-21-231-115
Comment: Copy from Bugs/CommonTasks to pages less lengthy
Revision 77 as of 2016-09-28 17:45:25
Size: 8361
Editor: es20490446e
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from Bugs/Bug status
## page was renamed from Bugs/Status
## page was renamed from BugSquad/ManagingStatus
<<Include(BugSquad/KBHeader)>>
Line 2: Line 6:
Bug statuses are a reflection of the current state of a bug report.  The state is a way to reflect the current progress of the bug report. A report's status is a reflection of the current development state of what is being reported.
Line 4: Line 8:
Below is a list of bug statuses, their meaning and when to use them: The status of a report can be modified by clicking on the current status in the yellow line, towards the top of the page. This will reveal a sub menu of statuses to choose from. You can then set a new status via the drop down box.

Below is a list of report statuses, their meaning, and when to use them:
Line 7: Line 13:
  * Bugs are submitted with this status,
  * They sometimes lack information and '''all''' of them should be untriaged
  * Reports are submitted with this status.
  * They sometimes lack information.
* All of them should be untriaged.
Line 10: Line 18:
  * 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 assign the bug to yourself so you will get the response.
  * a regular task for {{{Incomplete}}} bugs is to follow up and if there are no answers after a reasonable stage (a month), close them (as {{{Inavild}}} ) using the [:Bugs/Responses#head-6ee6466fdaac8c81274185f0316afd794d2ee0b6:Old Incomplete Response].
  * If you have to ask the reporter questions, set the report to Incomplete.
  * When you ask the reporter to provide any necessary information in a comment, and make sure you subscribe yourself to the report so you will get any updates to the report via e-mail.
  * If anyone, including you, makes a comments, the 60 day expiration clock is reset.
  * For more on this, please see [[https://wiki.ubuntu.com/Bugs/Responses]].

 * '''Opinion''':
  * This means there is a difference of opinion around the report 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 reports can be marked closed, so developers aren't wasting time on them, but discussion can still be on-going.
  * This status is considered an experiment, and will be closely monitored.
Line 14: Line 28:
  * Bugs marked as {{{Invalid}}} are closed and no longer show up in default searches
  * Be sure to triple-check a bug before you reject it.
  * This status means the report is closed, and no further triaging or development will continue towards it.
  * This status should be used when:
   * The report does not contain adequate information to determine whether or not it is a bug, even if it is resolved for the reporter.
   * The reported problem is not a bug at all. For example, the reporter's lack of knowledge on how something works, hardware failure, or fixed after updating a buggy, and outdated BIOS.
  * It should be used conservatively as reports marked as Invalid no longer show up in default searches.
  * Be sure to triple-check a report before you invalidate it.

 * '''Expired'''
  * This status is similar to Invalid, but is meant specifically for reports 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 reports, Expired reports do not show up in default searches.
Line 17: Line 41:
  * Someone believes that that the report describes a genuine bug in enough detail that a developer could start working on a fix
  * {{{Confirmed}}} bugs require confirmation from '''someone other than the original reporter'''
  * This helps ensure that the bug is applicable to Ubuntu in general, and not a problem with the reporter's system, therefore...
  * Please don't confirm your own bugs!
  * For all packages except for linux (Ubuntu):
   * Another reporter has experienced the same issue. This can come in the form of a duplicate report or a comment.
   * {{{Confirmed}}} reports require confirmation from '''someone other than the original reporter'''.
   * This helps ensure that the report is applicable to Ubuntu in general, and not hardware failure, lack of knowledge, etc.
   * In general, please don't confirm your own bugs, unless there is a documented exception by the development group of the package.
  * Only for linux (Ubuntu):
   * Confirmed means the original reporter has at least attached the minimum amount of information to begin triaging.
   * The original reporter has provided previously requested information.
Line 22: Line 51:
  * A member of Ubuntu QA believes that the report describes a genuine bug in enough detail that a developer could start working on a fix
  * Use this when you are confident that it should be looked at by a developer '''and''' has enough information
  * A member of [[Ubuntu Bug Control|https://wiki.ubuntu.com/UbuntuBugControl]] believes that the report describes a genuine issue in enough detail that a developer could start working on a fix.
  * Use this when you are confident that it should be looked at by a developer '''and''' has enough information for the developer to fix it.
  * While not a requirement, a report's Ubuntu task status should be Triaged before any upstream forwarding occurs.
  * With reports about '''linux''': Triaged means that the original reporter has tested with the latest upstream mainline kernel they can technically test to.
  * For process reports (e.g. [[FreezeExceptionProcess|FFes]] and [[SyncRequestProcess|syncs]]) Triaged means the action has been approved by the relevant developers.
Line 25: Line 58:
  * 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
  * You have assigned the report '''to yourself''', and you're going to address it '''right now''' by submitting a [[https://wiki.ubuntu.com/Bugs/Patches|patch]].
   * This status is not for if one is simply debugging (ex. bisecting, testing out a patch provided by someone else, you have a work around, etc.).
  * /!\ '''Never''' assign a report to others.
  * /!\ If there has been an assignee for more than six months without a fix or response, one could unassign them and revert the status.
Line 28: Line 64:
  * For upstream projects, the fix is in CVS/SVN/bzr or commited to some place
  * For package maintainers, 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. feisty-proposed
  * Ubuntu task: the changes are pending, and to be uploaded soon.
   * {{{Fix Committed}}} is also used when an updated package exists in a -proposed repository (i.e. trusty-proposed).
   * {{{Fix Committed}}} is '''not''' to be used when a patch is attached to a report.
  * Upstream task: the fix is in bzr/CVS/git/SVN, or committed to some place.
Line 32: Line 70:
  * For upstream projects, a release tarball was announced and is publicly available
  * For package maintainers, a fix was uploaded to an official Ubuntu repository
   * This '''does not''' include -proposed i.e. feisty-proposed
   * Please don't hesitate to add a changelog as a comment, so people know what to look out for
  * Ubuntu task: fixed in the latest Ubuntu release, as a standard upgrade.
   * /!\ If the bug stills affects an older Ubuntu release, please nominate it for that series. Otherwise people won't know it isn't fixed there!
   * Indicate which package version the fix was released in.

  * Upstream task: fix available in a tarball.

 * '''Won't Fix''':
  * This status is sometimes used when the fix is too controversial.
  * It is most often used for a report 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 [[UbuntuBugControl]] or package maintainers:

  * Moving to Triaged, or Won't Fix.
  * Moving ''from'' Won't Fix.
  * Targeting to a specific Ubuntu release.

=== Frequently Asked Questions ===

''If you have a question, please feel free to ask it by emailing the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad|BugSquad mailing list]] with your question.''

 * What is the appropriate status if the original reporter later says the issue no longer exists but the related changelog does not note a fix?
  * See the first point under "Invalid", the report 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 report open with a status of "Triaged", and/or mark it with [[Importance]] "Wishlist", depending on the severity.
 * Should the original reporter reset the report status to "New" if providing more information to an "Incomplete" report?
  * Yes.
 * When converting a question to a report, can the status immediately be set to "Confirmed" if comments in the question indicate that multiple users experience the issue?
  * Make a judgment call: as long as ''more than one person'' can reproduce it, the proper status is "Confirmed".
 * What should a triager do if a report needs more information, including steps to reproduce, but the original reporter is not available to provide it?
  * Mark the report as Invalid, with a comment that the reporter should provide the information, and reopen the report by resetting its status to 'New'.

||<tablestyle="width:90%;" style="width: 35px; border: none; -moz-border-radius-topleft: 15px ;-moz-border-radius-bottomleft: 15px; background-color: #F1F1DD; border: none; -moz-border-radius-topright: 15px;-moz-border-radius-bottomright: 15px; font-size: 1em; text-align: center;">{{attachment:IconHelp2.png}}Not yet a [[https://wiki.ubuntu.com/UbuntuBugControl|Ubuntu Bug Control]] member? If you notice a report having sufficient information and has not yet been set to Triaged, you'll have to ask someone who is to set the report to ''Triaged'' for you. Paste the report number in {{{#ubuntu-bugs}}} channel at [[https://wiki.ubuntu.com/FreeNode|FreeNode]] and say you think the report should be set to 'Triaged' with importance 'Wishlist / Low / Medium / High / Critical' according to [[Bugs/Importance]]. Someone will notice your comment and set it for you, although not necessarily immediately.||

----
CategoryBugSquad

information_little.png This page is part of the Bug Squad’s KnowledgeBase - pages with information about how to triage bugs.

A report's status is a reflection of the current development state of what is being reported.

The status of a report can be modified by clicking on the current status in the yellow line, towards the top of the page. This will reveal a sub menu of statuses to choose from. You can then set a new status via the drop down box.

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

  • New:

    • Reports are submitted with this status.
    • They sometimes lack information.
    • All of them should be untriaged.
  • Incomplete:

    • If you have to ask the reporter questions, set the report to Incomplete.
    • When you ask the reporter to provide any necessary information in a comment, and make sure you subscribe yourself to the report so you will get any updates to the report via e-mail.
    • If anyone, including you, makes a comments, the 60 day expiration clock is reset.
    • For more on this, please see https://wiki.ubuntu.com/Bugs/Responses.

  • Opinion:

    • This means there is a difference of opinion around the report 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 reports can be marked closed, so developers aren't wasting time on them, but discussion can still be on-going.
    • This status is considered an experiment, and will be closely monitored.
  • Invalid:

    • This status means the report is closed, and no further triaging or development will continue towards it.
    • This status should be used when:
      • The report does not contain adequate information to determine whether or not it is a bug, even if it is resolved for the reporter.
      • The reported problem is not a bug at all. For example, the reporter's lack of knowledge on how something works, hardware failure, or fixed after updating a buggy, and outdated BIOS.
    • It should be used conservatively as reports marked as Invalid no longer show up in default searches.
    • Be sure to triple-check a report before you invalidate it.
  • Expired

    • This status is similar to Invalid, but is meant specifically for reports 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 reports, Expired reports do not show up in default searches.
  • Confirmed:

    • For all packages except for linux (Ubuntu):
      • Another reporter has experienced the same issue. This can come in the form of a duplicate report or a comment.
      • Confirmed reports require confirmation from someone other than the original reporter.

      • This helps ensure that the report is applicable to Ubuntu in general, and not hardware failure, lack of knowledge, etc.
      • In general, please don't confirm your own bugs, unless there is a documented exception by the development group of the package.
    • Only for linux (Ubuntu):
      • Confirmed means the original reporter has at least attached the minimum amount of information to begin triaging.
      • The original reporter has provided previously requested information.
  • Triaged:

    • A member of https://wiki.ubuntu.com/UbuntuBugControl believes that the report describes a genuine issue in enough detail that a developer could start working on a fix.

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

    • While not a requirement, a report's Ubuntu task status should be Triaged before any upstream forwarding occurs.
    • With reports about linux: Triaged means that the original reporter has tested with the latest upstream mainline kernel they can technically test to.

    • For process reports (e.g. FFes and syncs) Triaged means the action has been approved by the relevant developers.

  • In Progress:

    • You have assigned the report to yourself, and you're going to address it right now by submitting a patch.

      • This status is not for if one is simply debugging (ex. bisecting, testing out a patch provided by someone else, you have a work around, etc.).
    • Warning /!\ Never assign a report to others.

    • Warning /!\ If there has been an assignee for more than six months without a fix or response, one could unassign them and revert the status.

  • Fix Committed:

    • Ubuntu task: the changes are pending, and to be uploaded soon.
      • Fix Committed is also used when an updated package exists in a -proposed repository (i.e. trusty-proposed).

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

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

    • Ubuntu task: fixed in the latest Ubuntu release, as a standard upgrade.
      • Warning /!\ If the bug stills affects an older Ubuntu release, please nominate it for that series. Otherwise people won't know it isn't fixed there!

      • Indicate which package version the fix was released in.
    • Upstream task: fix available in a tarball.
  • Won't Fix:

    • This status is sometimes used when the fix is too controversial.
    • It is most often used for a report 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.

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

  • Moving to Triaged, or Won't Fix.
  • Moving from Won't Fix.

  • Targeting to a specific Ubuntu release.

Frequently Asked Questions

If you have a question, please feel free to ask it by emailing the BugSquad mailing list with your question.

  • What is the appropriate status if the original reporter later says the issue no longer exists but the related changelog does not note a fix?
    • See the first point under "Invalid", the report 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 report open with a status of "Triaged", and/or mark it with Importance "Wishlist", depending on the severity.

  • Should the original reporter reset the report status to "New" if providing more information to an "Incomplete" report?
    • Yes.
  • When converting a question to a report, can the status immediately be set to "Confirmed" if comments in the question indicate that multiple users experience the issue?
    • Make a judgment call: as long as more than one person can reproduce it, the proper status is "Confirmed".

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

IconHelp2.pngNot yet a Ubuntu Bug Control member? If you notice a report having sufficient information and has not yet been set to Triaged, you'll have to ask someone who is to set the report to Triaged for you. Paste the report number in #ubuntu-bugs channel at FreeNode and say you think the report should be set to 'Triaged' with importance 'Wishlist / Low / Medium / High / Critical' according to Bugs/Importance. Someone will notice your comment and set it for you, although not necessarily immediately.


CategoryBugSquad

Bugs/Bug statuses (last edited 2016-10-03 15:32:33 by es20490446e)