BugWorkflow

Revision 8 as of 2006-11-09 21:02:33

Clear message

Summary

Use cases

The projects that use Launchpad for bug tracking can be classified into four broad types.

  • Small upstream: Bugs typically go directly from reported to Fixed, and there is no formal verification of fixes. Releases early and often, but there is often still some lag between fixes being committed and appearing in a release. Example: Gobby.
  • Large upstream: Large enough that vetting and clarifying new bug reports is a useful volunteer task in itself. Releases may have alphas and betas, so whether a bugfix has been "released" is a difficult question. Example: Firefox.
  • Web application: A production server is updated semi-regularly. , so there may beand there is lag between code land. Example: Launchpad.
  • Distribution: . Example: Ubuntu.

Rationale

Now that Ubuntu and a variety of upstreams are using Launchpad for bug tracking, we need to revisit the bug statuses available to see whether they allow and encourage useful bugtracking processes.

Design

Currently a bug in a particular place has bug statuses:

  • Unconfirmed (initial status)
  • Needs Info (needs clarification from the reporter, or someone else who can reproduce the problem)
  • Confirmed (enough information for a developer to start fixing it)
  • In Progress (currently being fixed)
  • Fix Committed (a fix has been included in the code, but this code is not necessarily available in a release)
  • Fix Released (the bug is fixed in a released version).

Whether a bug is a duplicate is orthogonal to its status.

Current plans are to introduce a "Not For Us" status (see MaloneSimplifications), which would mean that the bug is valid but is not going to be fixed in that particular place. (For example, a bug in Windows that cannot be worked around by an application it affects; or a bug in Ubuntu that is never going to be fixed for Dapper).

Problems with these statuses:

Implementation

Code changes

Schema changes

Data migration

Unresolved issues

Discussion

Definition of Bug Statuses

A bug workflow can move through the following logical states:

Untriaged means this bug report needs an experienced user or developer to evaluate the report and ensure it has enough information for a developer to reproduce the problem.

Triaging means the bug has been picked up by an experienced user or developer who is gathering enough information from the bug reporter (and possibly other people) to confirm or reject it.

Confirmed means an experienced user or developer has verified that the problem described by this bug report is a valid bug. It also means that there is enough preliminary information that a developer can reproduce or isolate the bug.

Rejected means this bug report is not a bug.

More Info means this bug needs more input to get fixed, e.g., from a UI specialist, DBA, etc. The bug may also turn out to have been trickier than it first seemed, and information gathered while Triaging was insufficient. This is distinct from Needs Info, because the bug has already been triaged.

In Progress means a developer is fixing this bug.

Fix Committed means the fix is available in the source code repository, but isn't yet available in an official release.

Fix Released means the bug has been fixed in an official release.

Closed/Verified means the bug has been fixed in an official release, and the fix verified by QA. See BugVerificationWorkflow.

Notes

Untriaged should be a status. Having Untriaged be a permission implies that you must know how important this bug is to fix to be able to say it's been triaged.

We don't currently have a Closed/Verified status, and Simon says there hasn't yet been a need for it. It's easy to imagine Closed/Verified being useful in a paid support scenario, but, because adding a new status is a quick change, we should wait until there is a pressing need for this status before adding it.

  1. Isolate the following categories of bugs, which should be addressed by Ubuntu developers:
    • Bugs which are specific to Ubuntu

      • Rationale: Either we created these bugs, and so they are our responsibility, or they are only manifest in our environment, in which case we are best equipped to diagnose them.

    • Other bugs which are very severe or relate to core goals of Ubuntu

      • Rationale: These bugs justify the direct attention of Ubuntu developers because they jeopardize our mission of producing high-quality releases

  2. Pass on all other categories of bugs to the appropriate party:
    • Complete bug reports which affect upstream should be made the responsibility of upstream (forwarded)

      • Rationale: The upstream community is better equipped to fix these bugs, and the fix should eventually go upstream anyway, so it's best for it to be fixed there in the first place

    • Incomplete bug reports should be made the responsibility of the reporter by requesting further information ("Needs info")

      • Rationale: Bug reports must be reasonably complete in order to be diagnosed by a developer. Because the development team is relatively small compared to the community of bug reporters, the development team must focus on complete reports.

    • Improper bug reports should be rejected

      • Rationale: Some bug reports are hopeless, for example if the reporter is unresponsive to questions, and must be abandoned in order for the bug system to remain manageable.

attachment:bug-workflow.png

["CategoryBugSquad"]