There are four ingredients for a bug tracking system to succeed, as
I see it:
1. Interest and cooperation from the developer community itself
2. The machine resources/network to support the system (available; I know
we have a machine here we could use, if no other, so it
is a certainty)
3. Good installation and customization of the system to provide good
catagorization of bugs (two people have volunteered with this part
of the problem, Kurt Wall, and Jeff Waugh (via private mail to me))
4. Someone (or set of people) to perform bug triage, entering existing
bugs initially, and once established, assign initial catagories,
mark duplicates, produce statistics as releases near, and
eventually cull the database of long fixed bugs.
1) is obviously essential. And 4) is needed to keep the quality up, so
that the developers don't go nuts (for example, what happened to the
nautilus folks during Gnome 2 development). Many of the major projects have
serious resources assigned to the triage/catagorization and maintenance
of their bug tracking systems. So 4) is also key (2, and 3 can be considered
solved problems, IMHO).
3) is a significant amount of work initially, and only a small amount
ongoing: if things aren't set up well (and tuned), then bug reports are
hard to deal with and don't go in the right directions. I gather some
previous attempts were not well done. I know that Jamey Hicks here spent
a number of days working out this catagorization stuff on the handhelds.org
bugzilla, so this is not just a one day and your done sort of job.
As Mike points out, establishing a transparent system would allow more
people to actually help on resolving problems. It is also a way for people
to get their feet wet on the project (as they do on some of the other
major projects) by taking bugs, working on fixes, and posting patches.
Some people even appear to enjoy this sort of work. With the current opaque
system, there is no way to enlist people into helping with bug fixing.
Some of the most valuable people in some other projects wander around
fixing lots, and lots, and lots of bugs.
This would help the scaling issue, I think, which XFree86 faces.
So the outstanding questions are:
1) are the people who do XFree86 developement interested/willing to work
with such a tool?
2) who is willing, if anyone, to become bugmeister and properly deal
with the database? This is a significant amount of work; one might
argue that the commercial Linux vendors are those with the most to
gain by helping out here.
I think answers to both in the affirmative are necessary before one goes
any further, and unless the answers our yes, we live with the current system
until there are credible answers.
If this is done, it had better be done well: I gather that previous attempts
have failed for various reasons, and I think good answers to all four
questions are essential.
- Jim
--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
[EMAIL PROTECTED]
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
