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]
Of course an easy “solution” to the newsgroup question posted above would be to have two separate Bugzilla directories (and databases) on one server, e.g.:
http://$servername/product1 and http://$servername/product2 (with accompanying localconf files).
This way, it’s also easier to manage permissions – but “my” solution is really only useful when the following applies:
– product1 and product2 have two completely separate code bases
– different products belong to different customers, i.e. it might be prudent to have different groups access different directories.
So summarizing the above only makes sense in a commercial (closed-source) environment, which is probably what the poster was referring to.
You’re dismissing this a bit too easily, perhaps because it would be hard to implement with bugzilla.
> If someone cares what absolute value a bug number has […]
I care. I can remeber “bug 4112” easily but for the life of me I don’t do very well with “bug 44275223212”. Six digits barely work for me; seven is not going to be fun.
What you are saying is that if an organization has lots of products (and presumably lots of bugs) then they either have to remember huge (and ever-growing) numbers or else they need multiple bugzillas. Either is suboptimal.
I don’t see anything conceptually hard about having one number series per product. If you needed to move a bug from one product to another it might get a new number, but so what? It would change from (product1,234) to (product2,125). Sure beats moving from one bugzilla to another.
People want unique bug numbers because it’s intuitive. While it may be technically wrong to assign meaning and value to something that should have none, it “feels right.” Part of having a good user interface is not fighting the user. You have a good argument that these users have a fundamental misunderstanding and should be educated, but I don’t think that it’s a product’s place to do so. Force-feeding your design decisions (even good ones) can frustrate users. To me that’s more likely to result in lower usage (i.e. fewer bug filings) than allowing them to preserve their illusions.
Furthermore, wanting unique bug numbering for different products is perfectly reasonable if (as Martin said) the products are independent. This is very common in commercial environments. Having multiple Bugzilla installations is a hack — it should be possible to have a single installation that can access multiple databases.
If you want to help people learn (instead of forcing them to), I think the simplest way is to stop referring to bug numbers, and start referring to bug IDs. People assign meaning to numbers, but most recognize that an ID is just some unique value without any inherent meaning. Throwing some letters into the ID would work wonders as well.
That breaks the first time you want to move bugs between products. Bug moving between instances of Bugzilla is far, far less nice than moving a bug between products, and requires a load of configuration.
You also feel the pain when people want customisations, and you have to make them to six instances instead of one.
Is it easier to remember six digits, or four digits plus some text (the name of the relevant product)? Anyway, we invented bug aliases so people won’t have to remember numbers of common bugs.
Well, you are going to hate Firefox, then :-)
It’s a UI design principle that the user doesn’t actually know what they want; asking users and building what they ask for produces terrible software.
Gerv,
To some extent I do agree with you that simply giving the end user what they want produces terrible software. However, I thought you also would have learned from recent decisions apart from the community (Style Sheet Switcher, View Source, etc).
I am the lead on a project to rewrite a group management system. The original project had a decent user base and at times the lead would make changes without ever asking the needs of the end user. This method resulted in us having to rewrite parts of our code so we could provide a product that was needed.
With our rewrite, I have a great concern for the needs of the end user. Will I implement everything they ask for? Absolutely not. However, I do want to get an idea of the needs of the end user and see how that works into the greater goal of the end user. You can design a ‘perfect’ product, but if there are no users, is it really worth it?
I can see both sides of the situation here. and both are logical implementations. The “problem” here is that Bugzilla was designed with the bug number being it’s actual reference ID in the report stack, as opposed to some other actual ID “handle” with which to manipulate the bug report. This has been already adressed in a cursory manner with bug aliases. The solution would be something very similar, Product bug numbers, apart from absolute bug database numbers. Bug 123,456 is also bug 1840 for Product Foo, while but 100,482 can be bug 1840 for Product Bar. you cna search by absolute bug number, or by product bug number. Absolute bug numbers don’t change when the bug moves from product to product, although product bug numbers would, since the product itself changes.
Bug 155,234 is misfiled as a bug for Product Foo, and given a product bug number of 1947. So, Gerv comes along and says “What a blinking moron to file this here” (as Gerv is wont to do, being the abusive godless heathen he is) and moved it to Product Bar, and is given a product bug number of 1879 (or whatever is next in unused numbers, obviously).
Now, this wouldn’t solve the problem of no gaps in the number line (numberspace?) without making product bug numbers useless as people-friendly handles, as whenever a bug is moved from one product to another you eithe rlive with a gap, or every bug above it in the number line drops one to fill the void.
So, gapless numbering is a pipe dream, but products having bug numbers is very doable, and could even be grafted on to the current Moz.org Bugzilla with a bit of effort. Or so say I speaking completely extemporaneously…
That sounds like a recipe for complete confusion :-|
“Let’s look at bug 12345.”
“Do you mean bug 12345, Product Foo bug 12345, or Product Bar bug 12345? Those are three different bugs.”
“I’m not sure. Er… let me check my notes.”
Of course it’ll cause confusion. The whole idea of different bug number-lines for different products is bad, but this is a simple solution to their “problem”. As you said, if they feel this is somehow needed, there’s something much more broken than bug numbering. :)
It’s a question of who has better knowledge of the problem domain: the person writing software for it or the person using the software and actually doing it. Life would be easier if that question had a consistent and conclusive answer.
Agreed.
In the case of Mozilla, Firefox, Thunderbird… yes, it’s bad. But if the products are independant it’s fine, wanted, and not harmful. I’m not advocating per-product numbering within a database — I think it should be possible to have a single installation that can access multiple bug databases. Program code should not be intertwined with user data. You do that for the prototype; you don’t leave it that way in the finished product. Requiring multiple Bugzilla installations is like requiring a seperate installation of MS Word for each document you want to edit. (Yes, it’s a pet peeve of mine.)
I agree with Grev.
If you have two products in one company with seperate bug counting systems (eg two installations of bugzilla) then it is going to cause confusion and misunderstanding.
For example, two people could be talking about “bug 1234”, which (so long as they don’t go into too much detail) could actually be two totally different bugs. If you have one set of bug numbers, then bug 1234 is quite obviously different to bug 2468.
As for the argument of long bug numbers, that is always going to be a problem to a certain extent, and splitting into two products/bug databases only partially eliminates that (remember you would need to split in to 10 products to reduce the average bug number length by one character). A better solution is to use a higher base number system, the obvious being base 36, that would turn bug 254,943 into bug 5GPR, for example.
I have solved this problem very easily – create a small template for printing the bug query, and add a counter in it. It shows both counter and actual bug number.
The requests for sequental no-holes bug numbers for the products is from old paperwork way for bug tracking. For example, safety-critical application development often must have a conformance to the ~30 years old standarts, which specifically checks for “don’t miss any bug written”
Michael Carman:
“Having multiple Bugzilla installations is a hack — it should be possible to have a single installation that can access multiple databases.”
It’s not really what I would call a “hack”. Just separate directories for cgi scripts and localconf files, separate MySQL databases and separate entries in httpd.conf, and you’re there.
————————————————-
Gerv:
“That breaks the first time you want to move bugs between products. Bug moving between instances of Bugzilla is far, far less nice than moving a bug between products, and requires a load of configuration.”
Why would you want to move bugs? The whole point of having separate directories (as described above) is that one never needs to move bugs (ideally speaking).
————————————————-
Gerv again:
“You also feel the pain when people want customisations, and you have to make them to six instances instead of one.”
Isn’t this really an advantage? Each Bugzilla can be tailored to its product requirements / characteristics.
————————————————-
Apologies for my slightly imprecise wording (English is not my first language), hope I got my points across.