On Customizing Bugzilla

Suppose you have an established QA process and are transitioning from an established tracker (ClearQuest) to Bugzilla 2.16. What changes might you want?

I recently saw a real company make real modifications. Most of the changes are depressing, we'll see an example bug entry form (<enter_bug.html>), an example bug (<show_bug.html>), an example bug activity (<show_activity.html>), and the query page (<query.html>). Some of the ideas behind the changes are good, but perhaps people can find a better way.

Background (Bugzilla 2.12)

Note that one requirement of any tracking system is a complete change log. Bugzilla normally does this by refusing to allow comment deletion / modification and storing any other changes in an activity log. The log has a per field length limit (256 bytes?), when a field is longer than the limit, the change is recorded by splitting it into multiple change records.

A long time ago, the CC fields was a single text field and Bugzilla suffered dataloss because changes in the activity table didn't deal well with it. But even before then, simply reading changes to the CC list was hard because most of the string was the same. As someone experienced with Bugzilla and the activity log, this is something that I remember with dismay.

Requirements of a converting QA team

A good bug has: QA needs to be able to see: Engineers need to be able to mark bugs for:

Requirements of a customer oriented company