Compiler Bugzilla

From Dmz-portal

Jump to: navigation, search

Contents

Overview

We based this on a two database model:"projects" and "issues".

The work flow is different for each one. It seems that the compiler Bugzilla database is closer to his "issues" database. We are striving for ease of use. We have thus combined some original attributes and deleted others.

When To Open a Ticket

A bug or task should be able to be completed. Please be specific and note exactly how resolution is tested.

Something like "The backend needs to be tested" in itself is not sufficient. How does it need to be tested, on what does it need to be tested, when is it tested enough?

If one wants a generic task that points to a series of specific tasks, please mark its TYPE as TRACKING. This allows for some structure without saddling the assignee to a "bug for life" that shows up at every bug blitz.

TYPE

How the ticket is used for searching and filtering.

BUG: Something broken in the product
TRACKING: Place-holder or long-term project usually blocked by other tickets
FEATURE: Something new that the product does not currently have or do
ENHANCEMENT: An improvement to an existing element of the product
INQUIRY: Somebody asking a question

STATUS

The current status of the ticket

OPEN: Bug submitted; probably assigned to default owner. A bug only returns to this state if it needs a new engineer assigned to it and it's unclear to the current owner who that would be.
ASSIGNED: Sent to the appropriate person.
CONFIRMED: The bug has been triaged and will be worked on soon.
IN PROCESS: Work has started and is continuing on the bug. This includes code in review.
BLOCKED: Work is not finished on the bug, but it is blocked for some reason like lack of test case or resources.
IN SUBMITTAL: Waiting for fix to be accepted into the main repository
RESOLVED: Work committed and declared done by owner
CLOSED: The bug has been verified fixed


The RESOLVED state will in addition have one of the following resolutions:

FIXED: The assigned engineer thinks the bug is fixed and needs outside verification.
INVALID: The premise for this bug is in error.
WONTFIX: Can't be fixed right now.
DUPLICATE: Same as another another bug. The duplicate bug number is required.
INSUFFICIENT INFO: The submitter was either too vague or lacked a test case. Unreproducible cases are also resolved to this state.

When setting something as RESOLVED and there is a link a commit or some other acceptance record, add the information in the Resolution References text box.

SEVERITY and PRIORITY

Severity describes the impact the bug has on the reporter. Priority describes how quickly the bug needs to be resolved. Here are 2 extreme examples illustrating the use of the 2 attributes:

SEVERITY

S1: The product crashes or doesn't work for customer
S2: The product is highly degraded for customer
S3: Normal, most bugs should fall here
S4: The customer isn't concerned about this bug

Hopefully having enumerated severities will take some of the emotion out of it

PRIORITY

P1: Most important bug. There will usually be only one P1 bug. The bug the engineer is focusing on unless it's blocked.
P2: Next most important bugs.
P3: Most bugs will be P3.
P4: Least important bugs.

Tracking nodes

Sometimes an engineer wants to have a different hierarchy for their bugs. This should be done with Tracking nodes. To make a Tracking node, a bug is created with the TYPE TRACKING and marked RESOLVED to avoid it showing up in management's bug lists. The type of resolution is up to the user. Then, any bugs that relate to this Tracking node, block it. One Tracking node can block other Tracking nodes, but an individual work item should only block a Tracking node never depend on a it.

Here is a picture of tasks that are connected to both a Tracking node on the left and a project goal on the right. The Tracking nodes are gray. The project goals are multicolored. The work items are white.

Place Holder.jpg

On the left is the engineer's hierarchy with 2 levels of TRACKING nodes. On the right are the release bugs. The release manager will be mostly interested in what is in this release whereas the engineer and/or engineering manager may want to know the full project layout regardless of which release they are a part of or even if the bug has been already closed.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox