When I left for my vacation almost three weeks ago, I had several review requests for Bugzilla patches pending. And this morning when I finally set out to get them all, they had vanished. Admittedly rather easy for me, although I wouldn't have minded about doing some either. I took one from the "from the wind queue", and it was wondrously easy though :-)
Slightly related: MaxKA filed bug 286822 ("Process Problem: Review From the Wind Never Happens") recently, explaining the issue that reviews never get done unless you choose the reviewer right - and choosing the right one requires extensive knowledge not publicly available for any new Bugzilla contributor. Max's effort of compiling a list of reviewer competencies is worthy, but the list will be difficult to maintain. Still, I can hardly imagine the situation would be worse than it's now.
One thing about "From the Wind" (requesteeless) review requests is that they often represent the most unreadable patches we ever get (all this is IMO, of course). The list tends to have a load of patches from people with no Bugzilla dev experience, they've just hacked something up for their site and then post the initial patch. Rather often, when you deny review, the patch vanishes forever as the author doesn't care enough about getting the code integrated. That said, it's exactly this group of Bugzilla users we should pay more attention to, as they do provide feedback in a way more constructive manner than the people just complaining about missing features.
However, taking into account the rather high quality requirements for new Bugzilla code, it'll be a hard task for a new developer to get his code if the only support he gets is in the form of reviews (which can be great support at times, admitted). It would be great to see the efforts behind Max's list evolve into a sort of tutoring program where special attention would be paid for writing clear and instructive review comments (unlike the vague and offensive ones we sometimes do now ;-)) and providing guidance even in the writing phase of the patch.
I should've said this quite some time ago already, but here goes: My sincere thanks to the "new" (well, it's certainly relative) group of developers that have shown up on the Bugzilla scene. It's great to see the product evolve even though most of the old team has vanished from sight. It's great to cvs up one's test installation every now and then and see the changes trickle in. Many great things have been done. MaxKA, LpSolit, Travis, Wurblzap, Wicked, Glob and everybody else I forgot to mention, keep it up! Perhaps your efforts will make my conscience throb painfully enough to force me to actually code something one day. :-)
Dennis Heuer posted an article called I, Bugzilla on OSNews. His essential claim is that Bugzilla makes life hell for open source users by making it ridiculously hard to get support. As the numerous reader comments on the article point out, his gripes are mostly about annoying personalities around OS projects, not the software itself. Not that I didn't agree with some points though; the default Bugzilla UI is a bit frightening. Luckily it is being worked on.
However, the article and its reader comments do raise several interesting points about open source project QA. Some readers claim that anybody creating OS software has a moral obligation to support it, and "Everybody here is a volunteer and under no obligation to fix your bug" is just bad behavior. If the quality and bug tracking of OS software is close to your heart, I suggest taking a quick read.
As for my personal opinion, even though I understand why people are inclined to expect some support even for free software, I find the ability to "fire-and-forget" code a very valuable characteristic of modern Internet-based software engineering. Take my Bugzilla contributions for example. If I had the moral obligation to support every line of code I've ever written, I just couldn't (and wouldn't) squeeze the time to implement any features that I don't need myself. The risks would be too big. The lack of permanent responsibility is what allows me to use my occasional spare time to do work that helps others.
Comparisons to freeware/shareware of the 90s aren't justified. The modern OS movement is the engine for huge products (Mozilla, Linux, OpenOffice...) where the touch of personal responsibility can never be what it used to be for all those euro calculators years back. The fact that much of the world's computing runs on software without a guaranteed support is somewhat frightening - but then again, am I any less convinced by the commercial apps?
Be it as it may, blaming the OS developers for not supporting their code forever isn't going to solve the issue. If you personally feel obliged to support every free code line you've given others, you have my respect. I try to be as supportive as possible, too. But when (not if) I fail because there's a life outside open source, I can't afford to feel too bad about it. If I did, it would increase the social cost of OS participation enough to stop me from doing it. I believe the same goes for a fair number of contributors.
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.
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?
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.
Yeah, the Bugzilla team has been crazy about this already, but I have to mention it too: Vladimir Vukicevic is developing a very promising tool called Bugwrangler. It's a system that allows you to create local metadata (custom keywords, personal priorities, freetext comments) on bugs and then use that metadata to sort bugs and whatever. It's not yet testable, but Vladimir's blog entry gives an idea.
Projects like this make developing Bugzilla worth it. People really use it, and they really work on making it more usable. And yeah, there certainly is a lot to be worked on. ;-)