Bug databases track issues at several levels.

There’s the level of the specific problem. For example: this sequences of graphics calls causes a crash.

Then there’s the level of the meta-bug: a bug tracking a number of different issues in some genre. For example, there might be a bug tracking, say, crashes involving some particular feature: graphics drawing functionality, for example. In Bugzilla this is known as a “meta-bug”, because it isn’t really a bug but rather a bug about bugs. In b.m.o such bugs are given the meta keyword.

Last, there’s the level consisting of bugs which track meta-bugs. For example, you might have a bug tracking a bug for crashes involving graphics drawing functionality, a bug for rendering glitches involving graphics drawing functionality, a bug for unimplemented functionality in the specification, a bug for performance problems involving graphics drawing functionality, and a bug tracking progress at investigating the relative stability of graphics functionality run on hardware with various graphics cards and driver versions. The logical progression is to call this a “meta-meta-bug”.

Therefore, shouldn’t Bugzilla have a meta-meta keyword to associate with such bugs? But let’s not be over-hasty: let’s have a fair discussion first. Perhaps people should comment or blog about this idea a bit. What do readers think?

It would be helpful, in terms of evaluating review request responsiveness, to have a way to look at a list of all bugs in a particular period of time in which a review has been requested of me, then either granted by someone else, transferred to someone else by the patch’s author, or removed due to a newer attachment being posted with review directed at someone else. The basic idea is to figure out how to measure whether other people are switching to other reviewers due to review latency, when requesters are sufficiently knowledgeable/motivated to switch rather than have an old review sit in a request queue forever. There’s no precise way to measure exactly this statistic. Someone else granting a review request might just be that that person was marginally more responsive on IRC to a quick request made after the initial flagging in Bugzilla. A review transfer may have been done with consent of both parties for reasons unrelated to review delay. A newer attachment with different reviewer might be an acknowledgment of a patch’s changing scope (whose most competent reviewer therefore changed). The point isn’t to get an exact idea, just to give the list of bugs so that one could examine the list, manually filter out false positives, and get some sort of rough idea of how good or bad review responsiveness has been.

A sufficiently granular bugmail search could probably tell me this, but I suspect extracting that information from lightly-structured text is much harder than working on Bugzilla or its data directly, and I’m not sure if my email account could easily accommodate such a search (and that solution’s not generally applicable).

So, lazyweb…make my life easier for me. 🙂