304 lines
11 KiB
ReStructuredText
304 lines
11 KiB
ReStructuredText
.. _understanding:
|
|
|
|
Understanding a Bug
|
|
###################
|
|
|
|
The core of Bugzilla is the screen which displays a particular
|
|
bug. Note that the labels for most fields are hyperlinks;
|
|
clicking them will take you to context-sensitive help on that
|
|
particular field. Fields marked * may not be present on every
|
|
installation of Bugzilla.
|
|
|
|
*Summary:*
|
|
A one-sentence summary of the problem, displayed in the header next to
|
|
the bug number.
|
|
|
|
*Status (and Resolution):*
|
|
These define exactly what state the bug is in—from not even
|
|
being confirmed as a bug, through to being fixed and the fix
|
|
confirmed by Quality Assurance. The different possible values for
|
|
Status and Resolution on your installation should be documented in the
|
|
context-sensitive help for those items.
|
|
|
|
*Alias:*
|
|
A unique short text name for the bug, which can be used instead of the
|
|
bug number.
|
|
|
|
*Product and Component*:
|
|
Bugs are divided up by Product and Component, with a Product
|
|
having one or more Components in it.
|
|
|
|
*Version:*
|
|
The "Version" field usually contains the numbers or names of released
|
|
versions of the product. It is used to indicate the version(s) affected by
|
|
the bug report.
|
|
|
|
*Hardware (Platform and OS):*
|
|
These indicate the computing environment where the bug was
|
|
found.
|
|
|
|
*Importance (Priority and Severity):*
|
|
The Priority field is used to prioritize bugs, either by the assignee,
|
|
or someone else with authority to direct their time such as a project
|
|
manager. It's a good idea not to change this on other people's bugs. The
|
|
default values are P1 to P5.
|
|
|
|
The Severity field indicates how severe the problem is—from blocker
|
|
("application unusable") to trivial ("minor cosmetic issue"). You
|
|
can also use this field to indicate whether a bug is an enhancement
|
|
request.
|
|
|
|
*\*Target Milestone:*
|
|
A future version by which the bug is to
|
|
be fixed. e.g. The Bugzilla Project's milestones for future
|
|
Bugzilla versions are 4.4, 5.0, 6.0, etc. Milestones are not
|
|
restricted to numbers, though—you can use any text strings, such
|
|
as dates.
|
|
|
|
*Assigned To:*
|
|
The person responsible for fixing the bug.
|
|
|
|
*\*QA Contact:*
|
|
The person responsible for quality assurance on this bug.
|
|
|
|
*URL:*
|
|
A URL associated with the bug, if any.
|
|
|
|
*\*Whiteboard:*
|
|
A free-form text area for adding short notes and tags to a bug.
|
|
|
|
*Keywords:*
|
|
The administrator can define keywords which you can use to tag and
|
|
categorise bugs—e.g. ``crash`` or ``regression``.
|
|
|
|
*Personal Tags:*
|
|
Unlike Keywords which are global and visible by all users, Personal Tags
|
|
are personal and can only be viewed and edited by their author. Editing
|
|
them won't send any notifications to other users. Use them to tag and keep
|
|
track of sets of bugs that you personally care about, using your own
|
|
classification system.
|
|
|
|
*Dependencies (Depends On and Blocks):*
|
|
If this bug cannot be fixed unless other bugs are fixed (depends
|
|
on), or this bug stops other bugs being fixed (blocks), their
|
|
numbers are recorded here.
|
|
|
|
Clicking the :guilabel:`Dependency tree` link shows
|
|
the dependency relationships of the bug as a tree structure.
|
|
You can change how much depth to show, and you can hide resolved bugs
|
|
from this page. You can also collapse/expand dependencies for
|
|
each non-terminal bug on the tree view, using the [-]/[+] buttons that
|
|
appear before the summary.
|
|
|
|
*Reported:*
|
|
The person who filed the bug, and the date and time they did it.
|
|
|
|
*Modified:*
|
|
The date and time the bug was last changed.
|
|
|
|
*CC List:*
|
|
A list of people who get mail when the bug changes, in addition to the
|
|
Reporter, Assignee and QA Contact (if enabled).
|
|
|
|
*Ignore Bug Mail:*
|
|
Set this if you want never to get bugmail from this bug again. See also
|
|
:ref:`emailpreferences`.
|
|
|
|
*\*See Also:*
|
|
Bugs, in this Bugzilla, other Bugzillas, or other bug trackers, that are
|
|
related to this one.
|
|
|
|
*Flags:*
|
|
A flag is a kind of status that can be set on bugs or attachments
|
|
to indicate that the bugs/attachments are in a certain state.
|
|
Each installation can define its own set of flags that can be set
|
|
on bugs or attachments. See :ref:`flags`.
|
|
|
|
*\*Time Tracking:*
|
|
This form can be used for time tracking.
|
|
To use this feature, you have to be a member of the group
|
|
specified by the :param:`timetrackinggroup` parameter. See
|
|
:ref:`time-tracking` for more information.
|
|
|
|
Orig. Est.:
|
|
This field shows the original estimated time.
|
|
Current Est.:
|
|
This field shows the current estimated time.
|
|
This number is calculated from ``Hours Worked``
|
|
and ``Hours Left``.
|
|
Hours Worked:
|
|
This field shows the number of hours worked.
|
|
Hours Left:
|
|
This field shows the ``Current Est.`` -
|
|
``Hours Worked``.
|
|
This value + ``Hours Worked`` will become the
|
|
new Current Est.
|
|
%Complete:
|
|
This field shows what percentage of the task is complete.
|
|
Gain:
|
|
This field shows the number of hours that the bug is ahead of the
|
|
``Orig. Est.``.
|
|
Deadline:
|
|
This field shows the deadline for this bug.
|
|
|
|
*Attachments:*
|
|
You can attach files (e.g. test cases or patches) to bugs. If there
|
|
are any attachments, they are listed in this section. See
|
|
:ref:`attachments` for more information.
|
|
|
|
*Additional Comments:*
|
|
You can add your two cents to the bug discussion here, if you have
|
|
something worthwhile to say.
|
|
|
|
.. _flags:
|
|
|
|
Flags
|
|
=====
|
|
|
|
Flags are a way to attach a specific status to a bug or attachment,
|
|
either ``+`` or ``-``. The meaning of these symbols depends on the name of
|
|
the flag itself, but contextually they could mean pass/fail,
|
|
accept/reject, approved/denied, or even a simple yes/no. If your site
|
|
allows requestable flags, then users may set a flag to ``?`` as a
|
|
request to another user that they look at the bug/attachment and set
|
|
the flag to its correct status.
|
|
|
|
A set flag appears in bug reports and on "edit attachment" pages with the
|
|
abbreviated username of the user who set the flag prepended to the
|
|
flag name. For example, if Jack sets a "review" flag to ``+``, it appears
|
|
as :guilabel:`Jack: review [ + ]`.
|
|
|
|
A requested flag appears with the user who requested the flag prepended
|
|
to the flag name and the user who has been requested to set the flag
|
|
appended to the flag name within parentheses. For example, if Jack
|
|
asks Jill for review, it appears as :guilabel:`Jack: review [ ? ] (Jill)`.
|
|
|
|
You can browse through open requests made of you and by you by selecting
|
|
:guilabel:`My Requests` from the footer. You can also look at open requests
|
|
limited by other requesters, requestees, products, components, and flag names.
|
|
Note that you can use '-' for requestee to specify flags with no requestee
|
|
set.
|
|
|
|
.. _flags-simpleexample:
|
|
|
|
A Simple Example
|
|
----------------
|
|
|
|
A developer might want to ask their manager,
|
|
"Should we fix this bug before we release version 2.0?"
|
|
They might want to do this for a *lot* of bugs,
|
|
so they decide to streamline the process. So:
|
|
|
|
#. The Bugzilla administrator creates a flag type called blocking2.0 for bugs
|
|
in your product. It shows up on the :guilabel:`Show Bug` screen as the text
|
|
:guilabel:`blocking2.0` with a drop-down box next to it. The drop-down box
|
|
contains four values: an empty space, ``?``, ``-``, and ``+``.
|
|
|
|
#. The developer sets the flag to ``?``.
|
|
|
|
#. The manager sees the :guilabel:`blocking2.0`
|
|
flag with a ``?`` value.
|
|
|
|
#. If the manager thinks the feature should go into the product
|
|
before version 2.0 can be released, they set the flag to
|
|
``+``. Otherwise, they set it to ``-``.
|
|
|
|
#. Now, every Bugzilla user who looks at the bug knows whether or
|
|
not the bug needs to be fixed before release of version 2.0.
|
|
|
|
.. _flags-about:
|
|
|
|
About Flags
|
|
-----------
|
|
|
|
Flags can have four values:
|
|
|
|
``?``
|
|
A user is requesting that a status be set. (Think of it as 'A question is being asked'.)
|
|
|
|
``-``
|
|
The status has been set negatively. (The question has been answered ``no``.)
|
|
|
|
``+``
|
|
The status has been set positively.
|
|
(The question has been answered ``yes``.)
|
|
|
|
``_``
|
|
``unset`` actually shows up as a blank space. This just means that nobody
|
|
has expressed an opinion (or asked someone else to express an opinion)
|
|
about the matter covered by this flag.
|
|
|
|
.. _flag-askto:
|
|
|
|
Flag Requests
|
|
-------------
|
|
|
|
If a flag has been defined as :guilabel:`requestable`, and a user has enough
|
|
privileges to request it (see below), the user can set the flag's status to
|
|
``?``. This status indicates that someone (a.k.a. "the requester") is asking
|
|
someone else to set the flag to either ``+`` or ``-``.
|
|
|
|
If a flag has been defined as :guilabel:`specifically requestable`,
|
|
a text box will appear next to the flag into which the requester may
|
|
enter a Bugzilla username. That named person (a.k.a. "the requestee")
|
|
will receive an email notifying them of the request, and pointing them
|
|
to the bug/attachment in question.
|
|
|
|
If a flag has *not* been defined as :guilabel:`specifically requestable`,
|
|
then no such text box will appear. A request to set this flag cannot be made
|
|
of any specific individual; these requests are open for anyone to answer. In
|
|
Bugzilla this is known as "asking the wind". A requester may ask the wind on
|
|
any flag simply by leaving the text box blank.
|
|
|
|
.. _flag-types:
|
|
|
|
.. _flag-type-attachment:
|
|
|
|
Attachment Flags
|
|
----------------
|
|
|
|
There are two types of flags: bug flags and attachment flags.
|
|
|
|
Attachment flags are used to ask a question about a specific
|
|
attachment on a bug.
|
|
|
|
Many Bugzilla installations use this to
|
|
request that one developer review another
|
|
developer's code before they check it in. They attach the code to
|
|
a bug report, and then set a flag on that attachment called
|
|
:guilabel:`review` to
|
|
:guilabel:`review? reviewer@example.com`.
|
|
reviewer\@example.com is then notified by email that
|
|
they have to check out that attachment and approve it or deny it.
|
|
|
|
For a Bugzilla user, attachment flags show up in three places:
|
|
|
|
#. On the list of attachments in the :guilabel:`Show Bug`
|
|
screen, you can see the current state of any flags that
|
|
have been set to ``?``, ``+``, or ``-``. You can see who asked about
|
|
the flag (the requester), and who is being asked (the
|
|
requestee).
|
|
|
|
#. When you edit an attachment, you can
|
|
see any settable flag, along with any flags that have
|
|
already been set. The :guilabel:`Edit Attachment`
|
|
screen is where you set flags to ``?``, ``-``, ``+``, or unset them.
|
|
|
|
#. Requests are listed in the :guilabel:`Request Queue`, which
|
|
is accessible from the :guilabel:`My Requests` link (if you are
|
|
logged in) or :guilabel:`Requests` link (if you are logged out)
|
|
visible on all pages.
|
|
|
|
.. _flag-type-bug:
|
|
|
|
Bug Flags
|
|
---------
|
|
|
|
Bug flags are used to set a status on the bug itself. You can
|
|
see Bug Flags in the :guilabel:`Show Bug` and :guilabel:`Requests`
|
|
screens, as described above.
|
|
|
|
Only users with enough privileges (see below) may set flags on bugs.
|
|
This doesn't necessarily include the assignee, reporter, or users with the
|
|
:group:`editbugs` permission.
|