Re: bugzilla (Was: What do you want me to do?) - Mailing list pgsql-hackers

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> 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
suspectwe 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? :-)

>  
>
>>. 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?
>
>  
>
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.

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