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 firstname.lastname@example.org. 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.