One “limitation” of Bugzilla is that bug numbers are unique in a particular installation. To most people, this may more like common sense than a restriction – but we regularly get questions in the newsgroup like this one:
If I have two products… and I add a new bug to Product1, the bug number is 1.
If I then add a new bug to Product2, the bug number is sequential (ie. 2). In
this example there would be no bug number ‘2’ for Product1. Ideally we would
want Product1 to have bug numbering sequentially specific to the product, so if there are 100 bugs for Product1 then the bugs are numbered from 1 to 100.
Usually, the questioner doesn’t explain why it is that they want to do this (although often it’s not them, but their management driving the request). If pressed, they sometimes say something about “easier to manage or understand” and “having no holes in the bug numbering space”. However, the root reason is almost always a serious misunderstanding about how software development in general, and bug tracking in particular, works.
If someone cares what absolute value a bug number has, or how many bugs there are in the system (either in total or for a particular product), then they must be attributing some meaning to those numbers. 95% of the time, their view is that the smaller the number of bugs, or the smaller the change in that number in a week, the less buggy the product. They often don’t realise that this is what they think, but they do.
Of course, a moment’s thought will reveal that this view is nonsense. The mozilla.org Bugzilla has over 250,000 bugs (it passed that milestone recently), including 47,000 open ones. The bug counts have increased steadily since the very beginning of the project. Does this fact by itself mean that Mozilla has been getting buggier and buggier since 1998? No, of course not.
It would therefore be tempting to dismiss such thinking as harmless foolishness. However, this attitude, and the culture that stems from it, can be far more damaging to good software development than one might think. If having fewer bugs is encouraged, then:
- people avoid the bug system and track bugs in spreadsheets, on post-it notes and on the back of their hand
- people check in lots of code under a single bug number, making it hard to see what changes went together
- problems fall through the cracks and don’t get reported at all.
Over and above all that, the person doesn’t normally explain what’s supposed to happen the first time a bug gets moved from one product to another, perhaps because it was originally misfiled. Do you change the number? Or have two the same number in a particular product?
The highest bug number in a bug system are a measure of only one thing – the number of times someone has pressed “Submit” on the entry form since you set the system up. Nothing else.
[Further reading (and my inspiration): Jouni Heikniemi]