Bugzilla and bug numbering per product
Every couple of months somebody pops up in the netscape.public.mozilla.webtools newsgroup and asks if he can make his Bugzilla number bugs so that the first bug for each product is #1. Most of the time the reasoning goes along the lines of "If a customer files bug 100 now and bug 200 a week later, he'll think the product is awfully buggy." Often, it continues with "Our bosses want the numbering to work that way".
Here are some of the recent threads: 1, 2, 3, 4, and here are some of the common answers:
Short and sweet: You can't do that with Bugzilla (unless you do significant changes to the codebase), and the team is not planning to implement support for that in the foreseeable future. If you absolutely must do it, have several installations of Bugzilla or be prepared for heavy-duty Perl hacking. That's really painful, I know. I'll start caring if you can convince me I'm wrong in what I say next.
The longer and even sweeter answer spans the rest of this blog post.
Any conclusions made from bug numbers are based on misconceptions. The only conclusion you can safely draw is that bug 2 was filed after bug 1 and before bug 3, but that's it. If you know the bug reporting patterns and habits for the organization using Bugzilla, you can make educated guesses. Unless you know, forget it. Bug numbers do not relate to bug counts in any relevant way.
Bugzilla has an extremely flexible query engine for a reason. You can use it to set up queries such as "Non-enhancement bugs in product X". That sort of queries are considerably better at measuring bug counts than pure bug numbers. You should tell your customers and bosses this. If they don't believe, retry after a while.
If they still don't believe, I have this one tip for you: Read the manual page on MySQL's AUTO_INCREMENT and make your bug numbers start from an arbitrary number with at least 7 digits. That greatly reduces the possibility that anyone would even consider them to represent any sort of counts. It's a surprise if they even notice any relation between the numbers of different reports.
Is fewer bug reports better?
The desire to control bug numbering is often a sign of more serious attitude problems related to software quality management. Before you address the question of bug numbering in your organization, consider the much broader question of bug filing culture first.
"Bugs" in Bugzilla are actually "work ticket suggestions". While they can be real bugs, they can also be enhancement requests, project management tokens or even help requests. Or duplicate reports thereof. In the big scheme, different products are just another source of randomness here. Should enhancement requests also get their own numbering?
The meaning of a bug number is to act as an identifying token that can be used as a reference both inside and outside the bug reporting tool. Binding the bug number to some of its characteristics has great inherent potential for confusion. The most obvious problem scenario rises when you have to move a bug between products. If you're absolutely convinced that will never happen you're either wrong or going to have little problem using separate Bugzilla installations anyway.
Sometimes – surprisingly often – a very fine-grained bug filing culture is best for the development. At my previous job we had a few projects where bugs were filed in great amounts. This wasn't an indication of the product's bugginess but of its complexity: As the number of code lines grew, the more importance was set on properly designing and splitting any task. The simpler the work items were, the easier it was to make sure they were done correctly. Usually that meant more small bugs instead of few big ones.
If your organization is struggling with bosses and customers that talk about needs for product-specific bug numbering, it is likely you still don't have real experience on systematic bug tracking. Don't make too many assumptions on your future bug-filing culture. While some organizations only add bug reports provided by customers, it's quite possible for a team to suddenly consider it beneficial to file their internal findings (usually tracked as TODO/FIXME code comments) in Bugzilla. If that happens, you have a choice to make: Do we allow developers to use this tool even if it makes the bug count grow? If not, what do we gain?
How do you want your bugs served – reported or hidden?
As a final word of caution, I'll say this: Even a query with the finest filtering can't usually replace professional human evaluation of the bugs listed. In the end, nobody cares about bug reports – it's bugs that people loathe. Take company A with a motivated testing team and an open bug policy. Take company B with the same product, no testing department and no centralized bug listing at all. B might have report counts that look much better than A's, but the illusion won't last long – A's product is bound to be better. Even if B suddenly got a testing department equivalent of A's, it would likely deliver a worse product – i.e. one based on less-informed decisions. The amount of bug reports correlates with the amount of information, not the amount of bugs.
If you strive to manipulate your visible bug material, are you doing it for the right reasons? Are you using the right methods? Closing your eyes or requiring certain severity for bugs "published" in Bugzilla doesn't make the issues go away. If you can't let your paying customers have an honest view of your product's state, forget about letting the customer have any access to your bug database and spend the resources on making your product better.
Don't shoot the messenger, shoot the bugs.
August 29, 2004
В· 
Jouni Heikniemi В· 
6 Comments
Posted in: Bugzilla
6 Responses
Hacking for Christ - September 10, 2004
Bugzilla "Limitations" 0: Introduction
I'm planning to write an occasional series of postings on "limitations" of Bugzilla which are actually features. As Joel has suggested (more than once; see three paragraphs from the bottom), sometimes you purposefully avoid adding a feature to a produc…
Hacking for Christ - October 21, 2004
Bugzilla "Limitations" 0: Introduction
I'm planning to write an occasional series of postings on "limitations" of Bugzilla which are actually features. As Joel has suggested (more than once; see three paragraphs from the bottom), sometimes you purposefully avoid adding a feature to a produc…
Hacking for Christ - October 31, 2004
Bugzilla "Limitations" 1: Bug Numbers Are Unique
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 …
kalala - June 13, 2007
Thank you,
I have one questions, I have read some links.
WHAT IS BUG NUMBER ONE?
Jouni - June 17, 2007
Bug 1 is whatever is the first entered bug in the system.
Angel17 - February 28, 2023
Such a nice read. This is so informative! local roofing company
Leave a Reply