Bug statuses

Differences between revisions 31 and 32
Revision 31 as of 2008-09-24 04:24:43
Size: 3817
Editor: c-24-21-234-111
Comment:
Revision 32 as of 2009-05-06 09:20:25
Size: 3919
Editor: mnch-5d860367
Comment: added reason for setting to Invalid
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
  * This should also be used if the reported problem is not a bug at all, but for example user error

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

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.
    • Include: Nothing found for "^== Incomplete bugs without a response from submitter =="!

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

      These standard responses along with other amazing scripts are also available as a Firefox extension in a PPA at:

      https://launchpad.net/~gm-dev-launchpad/+archive/ppa

      When you update one of these responses, you should also update the response used by the Firefox extension. These responses can be found in the bazaar branch lp:ubuntu-bugcontrol-tools in the file gm-xml-files/bugsquad-replies.xml. To check out a branch, use

      bzr branch lp:ubuntu-bugcontrol-tools

      Only members of bug-control can commit to this branch. But you can submit a merge proposal, Brian Murray will review/merge it (see this email message), and they can be used when replying to a bug report if merged.

      Not described well

      Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we cannot work on this bug because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.

      We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures.

      At a minimum, we need:

      1. The specific steps or actions you took that caused you to encounter the problem.
      2. The behavior you expected.
      3. The behavior you actually encountered (in as much detail as possible).

      Please also ensure that you include the release and flavour of Ubuntu that you are using.

      Thank you!

      Missing Steps to Recreate Bug

      Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:
      * Is this reproducible?
      * If so, what specific steps should we take to recreate this bug?

      This will help us to find and resolve the problem.

      Missing Apport Information

      Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:
      apport-collect BUGNUMBER

      When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

      Package or domain specific questions

      The following packages or type of bugs require the specific debugging information:

  • 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 closed bugs no longer show up in default searches
    • Be sure to triple-check a bug before you invalidate it
  • 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 Ubuntu in general, and not a problem with the reporter's system, therefore...
    • Please don't confirm your own bugs!
  • Triaged:

    • A member of UbuntuBugControl 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

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

    • For a bug task about an upstream project: the fix is in CVS/SVN/bzr or committed to some place
    • For an Ubuntu package: 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

  • Fix Released:

    • For a bug task about 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. hardy-proposed

      • Please don't hesitate to add a changelog as a comment, so people know what to look out for
    • If a bug is fixed in the current development branch, that is good enough for 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.

  • 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

Comments

  • What should a triager do if the bug's reporter later says the bug no longer exists, and the related changelog is nowhere to be found? NanleyChery

    • I believe this is covered by the first case under Invalid. BrianMurray


CategoryBugSquad

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