لطفا منتظر باشید ...
Hack 98. Survive Bugzilla
Survive and thrive in the scary world of
Mozilla's Bugzilla database.
Bugzilla,
like Firefox, is a product of the efforts of the Mozilla Foundation
and, before that, of Netscape Communications. Its home page is
http://www.bugzilla.org. Within
the Mozilla community, the Bugzilla installation at http://bugzilla.mozilla.org contains a great
deal of the workflow, history, current status, and collective memory
associated with Mozilla technology. This hack provides a brief
introduction.
9.9.1. Landing on Planet Bugzilla
Anyone can contribute to Mozilla's Bugzilla
database, but it is a place of work, not a place of play. Marc
Prensky's Digital Game-Based
Learning (McGraw Hill) describes a related concept called
"hard fun." Bugzilla requires
systematic rather than spontaneous participation, so any hard fun
only comes through hard preparation. Spontaneous participation is
poorly received in Bugzilla.
9.9.1.1 Differences between labor and work
In a normal workplace, such as an office, you might be accustomed to
a workflow that involves several people. When you hand tasks to those
after you, you expect them to be done. When people before you hand
tasks to you, they expect you to take them on. This is all based on
an obligation that you incurred. You agreed to supply labor in return
for money from the workplace. You can't meet your
obligation without assistance from your coworkers.
Bugzilla does not operate like that. Most participants are volunteers
or have solved the money problem. None, or very few, of the Bugzilla
participants have a labor contract. They work only because they want
to. As a result, most participants can do or
not do whatever they want. There is no point
making rules, because there is no labor obligation. Even those with
labor contracts are employed for what they might
do, rather than what they must do.
Regardless of how you judge Mozilla culture, it is this freedom of
individuals to wander about without any formal arrangement that makes
Mozilla a community.
9.9.1.2 Gift culture
If you put a piece of work into Bugzilla that someone else has cause
to appreciate, that's good for them. Eventually,
someone will put something into Bugzilla that you will have cause to
appreciate. That is all there is to it: nonspecific gift giving.
The gifts offered, however, are not entirely nonspecific. Software
development is an intensive activity that requires concentration.
People don't like their concentration being broken,
especially by irrelevancies. Gifts that fit with the narrow topics a
recipient works on are welcome. All other gifts are not. Precision
and accuracy in gift giving is very
importantlet's say
criticalin Bugzilla.
Furthermore, new gift givers represent a risk. The risk is that their
gifts might not be appropriate. The new gift giver could be a burden
on the whole community, which is trying hard to concentrate. It takes
existing participants a long time to let their guard down and accept
that a new participant is contributing in a way
that's reliable and not merely disruptive.
Typically, a gift offered in Bugzilla might just be a few sentences.
Said out loud, a few sentences carry little weight. In Bugzilla, they
carry a great deal of weight.
9.9.2. Dissecting Bug Reports
Each Bugzilla bug report contains several kinds of
information, all mixed together.
Figure 9-2. Essential fields for a bug report
This figures in this hack show the different sets of fields present
in a bug report. These screenshots are from the URL Figure 9-2 highlights the fields that contain the
essential information about the bug.
These few fields are all that's really required to
start a bug report. The bug number is generated automatically. These
fields are also just about all you need when doing a free text search
for bugs. It is not trivially obvious where the description
information is stored. It can be searched from
Bugzilla's query page using the
comments field. That's where it
resides.
As shown in Figure 9-3, the bug report is burdened
with lots of helpful information for beginners. Many of the links
lead nowhere, except to an explanatory Help screen. This is a little
confusing, because other controls on the page do form submission or
query requests. Perhaps one day, there'll be a
separate Help system for Bugzilla.
Figure 9-3. Help hotspots in a bug report
After the bug is entered, it starts its journey through a set of
states (the combination of Status and Resolution) until it reaches
its end. That end could be the garbage bin, an accepted new feature
of Mozilla or Firefox, or a number of other options. This is a
complex process, and the best way to learn it is to CC yourself on a
new bug or bugs and watch the email reports come in as work on the
bug progresses. During this journey, more information is added to the
bug that describes the problem or issue at hand, such as test cases
and patch fixes.
The particular bug being reported in Figure 9-4 has
no test-case attachments; instead, it has two candidate patch fixes.
Figure 9-4 shows all this in-process bug data and
the things to click or type into that add data to the bug.
Figure 9-4. Data entry and data for a bug report
While the bug report is underway, lots of people are interested in
it. They show their interest by adding their email addresses and by
marking the bug in many different ways. This marking behavior
supports each interested person's own work
practices; they can then recall the bug using special or standard
queries.
Release Managers, module owners, and QA people need these marks to
get their jobs done, so there are some standard and agreed-upon marks
that shouldn't be used for other purposes. If a mark
includes a +, that means "looking
good for a given release" (good news). If a mark
includes a -, that means "this
bug is to be stalled or slipped past a given
release" (bad news). A + used on
a version number has a different meaning than a +
as described above; when used on a version it means
"this is a trunk version that includes experimental
changes on top of the noted release." Figure 9-5 points out examples of many marks.
Figure 9-5. Marks and observers placed in a bug report
Finally, the bug report contains more information than can possibly
fit on one page. A number of bug-report features just replace the
current page with special reports and ancillary information about the
bug, as shown in Figure 9-6.
Figure 9-6. Ancillary information for a given bug report
Try loading up this page and running through the screenshots in
Figure 9-2 through Figure 9-6. There's no substitute for
experience with Bugzilla, but some early orientation can help.
