|
For a long time I have resisted moving our bug tracking
mailing list onto a formal Defect Tracking System. DTSs are in
general expensive to purchase and deploy, expensive to maintain, and a pain to
use. A lot of features they offer
(like collaboration and searching) we already have with our bugrack
mailing list. Recently however, we
have:
The combination of these has made following the traffic on bugtrack and trying to match the activity there to
subsequent product releases unworkable. About six weeks ago we initiated a project to deploy Bugzilla as our
Defect Tracking System. Bugzilla is an Open Source DTS system originally created
for the Mozilla project (aka,
Netscape Navigator). It is a
full-featured DTS with bug numbers, product and component categorization,
priority, severity, engineer assignment, attachments, and of course, the status
of the bug. Here is what we hope to gain with the move from bugtrack to Bugzilla:
Of course, you don’t get anything for free. There are a few of downsides to the
move:
We are confident that the pros outweigh the cons, but there
are going to be adjustments. Any
change is inevitably disruptive.
Please be patient during the transition. There is really no way to run both bugtrack
and bugzilla concurrently, and as such, we are shutting down the bugtrack mailing
list this afternoon. If
you send a message to bugtrack, you will get an email
reply directing you to Bugzilla. We have imported 1129
bugs into the Bugzilla database, and will do a “final import” of the last few weeks’ bugs
this afternoon. As we bring Bugzilla into sync, you will see a lot of activity relating
to these past weeks’ bugs and some ancient bugs that still need to be
categorized. In the mean time,
don’t put too much stock in the timestamps you see on Bugzilla
activity, and assume that bugs that were marked as fixed on bugtrack
really are fixed even if Bugzilla doesn’t know
about it yet. By the end of the
week this activity should settle down. All of the rules for
submitting bugs to bugtrack apply to Bugzilla. Bugzilla comes with some generic bug writing
guidelines that are a good start, though much of the discussion
doesn’t apply to our products.
We will customize those guidelines for our own specific needs as we all
become more familiar with the system.
Of particular importance is that you only
describe one bug per Bugzilla
submission. Because of the tight
coupling between Bugzilla and the readme
entries and source code changes, we simply cannot tolerate multiple bugs per submission. These submissions will be marked as WONTFIX. We ask (beg, plead) for your cooperation
in this matter. The first time you make a submission to Bugzilla,
the system will prompt you for a username and password. Use the same username and password as
you use to access the staff site.
The system is pretty self explanatory, and has hyperlinks to help on
each page. Again, we will be
customizing these help files as we move forward. If you have any general questions on Bugzilla use, post a message to the support list and we
will try to shed some light. If you
have questions about a specific bug or just want a warm body to talk to,
contact Ravina and she can also help
you out. I would have preferred a
Hawaiian retreat to teach everyone Bugzilla, but the
request didn’t go through. You can modify your email
preferences to tell Bugzilla the kind of bug
notifications you want to hear about.
Bugzilla can be pretty verbose (even more so
than bugtrack), so we recommend you set your
notifications to a minimum to start.
Bugzilla notifications come from the email
address bugzilla-daemon@staff.gesn.com. You’ll want to set up a new email
organize rule to sort these messages into a separate folder. Do not reply to
these messages. This is going to be
the hardest part to get used to, since that was standard operating procedure
with bugtrack.
If you have additional comments to make regarding a bug, click on the
hyperlink in the bugzilla-daemon email, and make your
comment inside Bugzilla. After we get Bugzilla
in sync with the bugtrack mailing list, we will be
sending out an automated weekly bug summary email that reviews the week’s
bug activity. This will help
maintain the “push” nature of the bugtrack
mailing list, while not inundating people with a flood of emails they
can’t follow. As I final note I would like to thank Josh for deploying Bugzilla on our server, and authoring the scripts to
populate the database with our bugtrack archive. A special thanks to Tracy, Nel, and
Whitman who then took on the manual and unenviable task of categorizing
1129-odd bugtracks into assignees, product, version,
and status. Without their efforts
this project would not have been possible. Ken |