Fedora: Bug Tracking != Incident Tracking != Project Tracking

Bugzilla like most bug-tracking software is an extremely useful tool. It can be used for tracking incidents, bugs, service requests, project plans, etc.. it is the screwdriver of Fedora/Red Hat that gets used by developers,etc for a hammer, plunger, and any other tool that is needed. And that is a major problem for people when they look at it.

A good while ago, I looked for open bugs in Kerberos, and found some that I had opened at a former job in 2003ish. According to bugzilla they had not been looked at, touched, felt, changed etc.. and that made me very pissed. Then I remembered that I had talked to the developer a couple of times on those very bugs. He was using the bugs as a reminder that this was a long standing issue that needed to be dealt with in RHEL-2.1 at some point or to see if it showed up later. My guess was that he and I both forgot about it as it didn't show up in later versions and well I wasn't so bothered by it that I opened up a trouble ticket with Red Hat. However, looking at it fresh from 4 years later.. my immediate emotional reaction was anger.. and a week later it became a problem with my former job and Red Hat because the former workplace saw it as money they wasted with Red Hat.

Now there are lots of ways the ticket could have been dealt with... most of them things I should have done.. but I would like to outline one that might be useful.

Keeping the ticket in the main bugzilla was useful for a while with the developer because he could track it as something that might be a bigger problem or was part of a project.. but it was not easy for someone outside to see it, nor was it useful after we both forgot it. And its not hard to forget it when you have a package with hundreds of 'issues' that need to be fixed or tracked with upstream.

Anyway my pondering on this made me wonder if there was a way to split up the bug database into multiple 'sub-ones' with an overall tracker available. The sub databases would be 'triage' where all initial bugs go into, 'incident' where things that are obviously broken get pushed to for a patch to be tracked and put out on, and 'project' where bugs in triage that are going to take a large amount to fix go. Incidents might go out there if the fix is a work-around but the real fix is a major rewrite. There might be another one or two (service requests), but I think those 3 cover the majority (80% solution) of what Bugzilla gets used for. People when putting in a bug see it goes into triage. There is gets dealt with by a set of people who get enough info to see if it goes somewhere else in the hierarchy and what the 'priority' of the bug would be (the background is supposed to be fe:00:00 not fd:00:00 is low, bash drops setuid core dumps is a bit higher.) and then it gets pushed to incidents or projects where it lives out its merry long life.

Anyway, a brainstorm I figured I needed to write before I forgot.