Andrew Dunstan <[EMAIL PROTECTED]> writes:
Bugzilla is far from perfect. But it's getting better.
FWIW, I would like to try a bugzilla-based tracking system for Postgres. Our last attempt at a tracking system failed miserably, but I think that was (a) because the software we tried was really unpolished, and (b) because we let anybody and his pet chihuahua enter bug reports, so the signal-to-noise ratio went to zero in no time. As long as we can restrict data entry to people who know what they're doing (not necessarily developers, but people who know PG well enough to tell bug from user error), I think it could work, and would beat the heck out of the way we do things now.
. if we used bugzilla this might give some impetus to the bugzilla team's efforts to provide pg as a backend (maybe we could help with that)
Red Hat has been using a PG-based version of bugzilla for some time. I'm not sure what the holdup is in getting that work merged back upstream, but I'd sure like to see it happen. Anyway we could start with using their version, rather than suffer the ignominy of using That Other Database to track our own bug reports ;-)
The status of this can be seen at: http://bugzilla.mozilla.org/show_bug.cgi?id=98304
This item is listed on their "Master Plan" page at http://www.mozilla.org/projects/bugzilla/roadmap.html as being in the category "Things we want in 2.18 but will get pushed to 2.20 if they're not completed by the time everything in the above list". I'd hate that to happen.
The last comment on the bug page says:
"The Red Hat guys did a quick 'n dirty port. It works, but doesn't quite make use of the best of PostgreSQL. Also, their tarball is out of date with the current schema used by Bugzilla."
My experience is that migrating to new versions of bugzilla is a major pain, so I'd hate to start out with something we suspect we would have to throw away later.
The bug is actually assigned to David Lawrence at RedHat - maybe you'd like to get some status from him? :-)
All good points. Bug triage is critical to success in my experience. You can take the suggested approach of trying to rule them out before they get into the system, or be aggressive about triage when they do get there - I've seen both work. RedHat allows anybody (with or without pooch) to sign up for an account and enter bugs, and I've had good responses myself from them for bugs I've filed. There is a certain niceness and openness about doing things that way, and I'm not sure the triage effort is any greater. Your housekeeper looks at today's list and either rules something not a bug or assigns it. For emailed bugs I agree doing triage before they get into the system makes sense.
. are there any active developers without web access? If not, why is pure email interaction important?
Bugzilla already does email output (ie, notify you of changes to bug entries you're interested in) well enough. We thought during the last go-round that it was important to have email input so we could allow mail to pgsql-bugs to go directly into the tracking system, but in hindsight that was a really bad idea. What we could use instead is for someone knowledgeable to commit to transferring *valid* emailed bug reports into the tracking system. Bruce could do that if he wants, but there are surely dozens of other people who would be qualified to handle this task.
Actually, whatever software we pick to run the tracking system, my guess is that the experiment will not stand or fall on the software. What we need for success is one or two people who will take responsibility for housekeeping: putting in valid reports, spotting duplicate reports and doing the right cleanup, etc. Do we have any volunteers for that sort of thing?
And, since I have argued for it I guess I should volunteer to help, although my knowledge of pg internals is still on the steep part of the learning curve.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
