BUGZILLA

STATUS
The Status field indicates the current state of a bug. Only certain status transitions are allowed.

RESOLUTION
The Resolution field indicates what happened to this bug.
(No resolution yet. All bugs which are in one of these "open" states have no resolution set.)

OPEN BUGS

UNCONFIRMED
This bug has recently been added to the database. Nobody has validated that this bug is true.
Users who have the "canconfirm" permission set may confirm this bug, changing its state to
NEW. Or, it may be directly resolved and marked RESOLVED.

NEW
This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in
this state may be accepted, and become ASSIGNED, passed on to someone else, and remain
NEW, or resolved and marked RESOLVED.

ASSIGNED
This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to
another person and become NEW or resolved and become RESOLVED.

REOPENED
This bug was once resolved, but the resolution was deemed incorrect. For example, a
WORKSFORME bug is REOPENED when more information shows up and the bug is now
reproducible. From here bugs are either marked ASSIGNED or RESOLVED.

READY
This bug has enough information so that the developer can start working on a fix. The bug has the
required test cases, crash data, detailed specs, etc. Bugs in this state may be accepted, and become
ASSIGNED, passed on to someone else, and remain READY, or resolved and marked
RESOLVED.
 STATUS
CLOSED BUGS
RESOLVED
A resolution has been taken, and it is awaiting
verification by QA. From here bugs are
either re-opened and become REOPENED
, or are marked VERIFIED.
VERIFIED
QA has looked at the bug and the resolution
and agrees that the appropriate resolution
has been taken. Any zombie bugs that
choose to walk the earth again must do
so by becoming REOPENED.
Other Fields
RESOLUTION
FIXED
A fix for this bug is checked into the tree and tested.
INVALID
The problem described is not a bug.
WONTFIX
The problem described is a bug which will never be
fixed.
DUPLICATE
The problem is a duplicate of an existing bug.
Marking a bug duplicate requires the bug# of the
duplicating bug and will at least put that bug number
in the description field.
WORKSFORME
All attempts at reproducing this bug were futile, and
reading the code produces no clues as to why the
described behavior would occur. If more
information appears later, the bug can be reopened.
INCOMPLETE
The problem is vaguely described with no steps to
reproduce, or is a support request. The reporter
should be directed to the product's support page for
help diagnosing the issue. If there are only a few
comments in the bug, it may be reopened only if the
original reporter provides more info, or confirms
someone else's steps to reproduce. If the bug is long,
when enough info is provided a new bug should be
filed and the original bug marked as a duplicate of it.
Alias
A short, unique name assigned to a bug in order to assist with looking it up and referring to it in
other places in Bugzilla.
Assignee
This is the person in charge of resolving the bug. Every time this field changes, the status changes
to NEW to make it easy to see which new bugs have appeared on a person's list.

Blocks
This bug must be resolved before the bugs listed in this field can be resolved.
Bug ID
The numeric id of a bug, unique within this entire installation of Bugzilla.
CC
Users who may not have a direct role to play on this bug, but who are interested in its progress.
Changed
When this bug was last updated.
Classification
Bugs are categorized into Classifications, Products and Components. Classifications are the top-
level categorization.
colo-trip
A custom Drop Down field in this installation of Bugzilla.
Comment
Bugs have comments added to them by Bugzilla users. You can search for some text in those
comments.
Component
Components are second-level categories; each belongs to a particular Product. Select a Product to
narrow down this list.
Content
This is a field available in searches that does a Google-like 'full-text' search on the Summary and
Comment fields.
Crash Signature
A custom Large Text Box field in this installation of Bugzilla.
Creation date
When the bug was filed.
Depends on
The bugs listed here must be resolved before this bug can be resolved.
Due Date
A custom Date/Time field in this installation of Bugzilla.

Hardware
This is the hardware platform against which the bug was reported. Legal platforms include:
 All (happens on all platforms; cross-platform bug)
 x86_64

 ARM
 Note: When searching, selecting the option All does not select bugs assigned against any
platform. It merely selects bugs that are marked as occurring on all platforms, i.e. are designated
All.
Keywords
You can add keywords from a defined list to bugs, in order to tag and group them.
Last Resolved
A custom Date/Time field in this installation of Bugzilla.
Locale
A custom Multiple-Selection Box field in this installation of Bugzilla.
Office/Space
A custom Drop Down field in this installation of Bugzilla.
OS
This is the operating system against which the bug was reported. Legal operating systems
include:
 All (happens on all operating systems; cross-platform bug)
 Windows 7

 Mac OS X

 Linux

Sometimes the operating system implies the platform, but not always. For example, Linux can
run on x86_64, ARM, and others.
Priority
This field describes the importance and order in which a bug should be fixed compared to other
bugs. This field is utilized by the programmers/engineers to prioritize their work to be done.
Product
Bugs are categorized into Products and Components. Select a Classification to narrow down this
list.
QA Contact
The person responsible for confirming this bug if it is unconfirmed, and for verifying the fix once
the bug has been resolved.
Reporter
The person who filed this bug.

See Also
This allows you to refer to bugs in other installations. You can enter a URL to a bug in the 'Add
Bug URLs' field to note that that bug is related to this one. You can enter multiple URLs at once
by separating them with a comma.

You should normally use this field to refer to bugs in other installations. For bugs in this
installation, it is better to use the Depends on and Blocks fields.

Severity
 This field describes the impact of a bug.
blocker Blocks development and/or testing work
critical crashes, loss of data, severe memory leak
major major loss of function
normal regular issue, some loss of functionality under specific circumstances
minor minor loss of function, or other problem where easy workaround is present
trivial cosmetic problem like misspelled words or misaligned text
enhancement Request for enhancement

Summary
The bug summary is a short sentence which succinctly describes what the bug is about.

Target Milestone
The Target Milestone field is used to define when the engineer the bug is assigned to expect to fix
it.
URL
Bugs can have a URL associated with them - for example, a pointer to a web site where the
problem is seen.
Version
The version field defines the version of the software the bug was found in.
Votes
Some bugs can be voted for, and you can limit your search to bugs with more than a certain
number of votes.
Whiteboard
Each bug has a free-form single line text entry box for adding tags and status information.

 Severity is used to indicate how "bad" a problem is. It's a more objective rating that in theory
should typically stay constant throughout the life of the issue.

 Priority is used as a project management tool to indicate how important an issue is for the current
release, milestone, and/or sprint. Because it's used for planning, the priority value is more likely
than severity to be dynamic over the life of the issue.

Priority Definition
P1 Cannot ship without this Bugzilla
P2 Highly desirable and planned for this release, but not stop ship
P3 Of interest, but not planned or expected in this release
P4 Not used by TPTP
P5 Not used by TPTP
Severity Definition
blocker Prevents function from being used, no work-around, blocking progress on multiple
fronts
critical Prevents function from being used, no work-around
major Prevents function from being used, but a work-around is possible
normal A problem making a function difficult to use but no special work-around is required
minor A problem not affecting the actual function, but the behavior is not natural
trivial A problem not affecting the actual function, a typo would be an example

Bugzilla Mappings
Bugzilla comes with its own terms for handling severity and priority. Below is a table showing how we
will map those to the terms used above:
Severity

Bugzilla GitHub: Maqetta Priority

blocker
Severity 1 Bugzilla GitHub: Maqetta
critical
major Severity 2 P1 Priority Critical
normal Severity 3 P2 Priority High
minor Severity 4 P3 Priority Med
P4
enhancement do not use* Priority Low
P5

* NOTE: Do not use the enhancement severity in Bugzilla, as it does not accurately denote a level of
severity.

Severity

The available tags for severity are as follows:

 Severity 1
o Critical customer/product impact. This indicates you are unable to use the overall product
resulting in a critical impact on operations. This condition requires an immediate
solution.

o The product is unable to operate or the product caused other critical software to fail and
there is no acceptable way to work around the problem.

 Severity 2

o Significant customer/product impact. This indicates the product is usable but is severely
limited.

o Severely limited can mean that a task is unable to operate, the task caused other critical
software to fail, or the task is usable but not without severe difficulty.

o Serious performance degradation might fall into this category unless it was so bad as to
render the system completely inoperative.

o This can mean that function which you were attempting to use failed to function, but a
temporary work-around is available.
  Severity 3
o Some product impact. This indicates the program is usable but a task runs with minor
issues/limitations.

o The task that you were attempting to use behaved in a manner which is incorrect and/or
unexpected, or presented misleading or confusing information.

o This can include documentation which was incomplete or incorrect, making it difficult to
know how to use a task.

o This can include poor or unexplained log messages where no clear error was evident.

o This can include a situation where some side effect is observed which does not
significantly harm operations.

o Documentation that causes the customer to perform some operation which damaged data
(unintentional deletion, corruption, etc.) would more likely be listed as a severity 2
problem.

o This can not include cases where customer data is inaccurately stored, or retrieved. Data
integrity problems require a severity of 2 or higher.

 Severity 4

o Minimal product impact. This indicates the problem causes little impact on operations or
that a reasonable circumvention to the problem has been implemented.

o The function you were attempting to use suffers from usability quirks, requires minor
documentation updates, or could be enhance with some minor changes to the function.

o This is also the place for general Help/DOC suggestions where data is NOT missing or
incorrect.

Priority

The available tags for priority are as follows:

 Priority Critical
o Cannot ship the release/milestone until completed.

o Should be addressed immediately before any lower priority items.

 Priority High

o Part of the "must-include" plan for the given milestone

 Priority Medium

o Highly desirable but not essential for given milestone.

 Priority Low
 o Desirable for given milestone but not essential, should be pursued if opportunity arises to
address in a safe and timely manner.

BUGZILLA – BUG WRITING GUIDELINES

Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.

Principles
 Be precise
 Be clear - explain it so others can reproduce the bug

 One bug per report

 No bug is too trivial to report - small bugs may hide big bugs

 Clearly separate fact from speculation

Preliminaries
1. Reproduce your bug using a recent build of the software, to see whether it has already been
fixed.
2. Search Bugzilla, to see whether your bug has already been reported.

Reporting a New Bug

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:
1. Choose "Enter a new bug"
2. Select the product in which you've found the bug
3. Fill out the form. Here is some help understanding it:

Component: In which sub-part of the software does it exist?

This field is required. Click the word "Component" to see a description of each component. If none seems
appropriate, look for a "General" component.
OS: On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)
If you know the bug happens on more than one type of operating system, choose All. If your OS isn't
listed, choose Other.

Summary: How would you describe the bug, in approximately 60 or fewer characters?
A good summary should quickly and uniquely identify a bug report. It should explain the problem, not
your suggested solution.

 Good: "Cancelling a File Copy dialog crashes File Manager"

 Bad: "Software crashes"

 Bad: "Browser should work with my web site"

Description: The details of your problem report, including:

Overview: More detailed restatement of summary.

Drag-selecting any page crashes Mac builds in the NSGetFactory

function.

Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup
steps.

1) View any web page. (I used the default sample page,

resource:/res/samples/test0.html)

2) Drag-select the page. (Specifically, while holding down

the mouse button, drag the mouse pointer downwards from any
point in the browser's content region to the bottom of the
browser's content region.)

Actual Results: What the application did after performing the above steps.

The application crashed.

Expected Results: What the application should have done, were the bug not present.
The window should scroll downwards. Scrolled content should be
selected.
(Or, at least, the application should not crash.)

Build Date & Hardware: Date and hardware of the build in which you first encountered the bug.
Build 2006-08-10 on Mac OS 10.4.3

Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if
applicable).
Doesn't Occur On Build 2006-08-10 on Windows XP Home (Service Pack 2)

Additional Information: Any other useful information.

For crashing bugs:

 Windows: Note the type of the crash, and the module that the application crashed in (e.g.
access violation in apprunner.exe).
 Mac OS X: Attach the "Crash Reporter" log that appears upon crash. Only include the section
directly below the crashing thread, usually titled "Thread 0 Crashed". Please do not paste the
entire log!

Double-check your report for errors and omissions, then press "Commit". Your bug report will now be in
the Bugzilla database.