Re: Bug tracker tool we need - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Bug tracker tool we need
Date
Msg-id 4F8E3394.5040801@2ndQuadrant.com
Whole thread Raw
In response to Re: Bug tracker tool we need  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug tracker tool we need
List pgsql-hackers
On 04/17/2012 10:30 PM, Tom Lane wrote:

> Indeed.  The only one I've got extensive experience with is Bugzilla
> (because Red Hat uses it) and I do cordially hate it.  At least some
> of that is due to bureaucratic practices RH has evolved, like cloning
> bugs N times for N affected releases, but I think the tool encourages
> such things.

That's along the same lines as my comments toward Jay Levitt, that bugs 
where the fixes span multiple releases are the part nobody seems to 
handle very well.

Rather than talk about adopting one of the available torture devices, 
I'd happily consider the simplest thing possible that would be useful 
here instead.  Here's my proposed tiny tracker:

-If a bug is found in a released version, but it didn't originate on 
pgsql-bugs, send a message to that list so it gets assigned a bug id.

-Write something that consumes pgsql-bugs and dumps all bug numbers and 
their subject lines into a database.  Start them with a state of 
"Unconfirmed".

-Make commits that fix a bug reference it in one of the standard ways 
that's done by every one of these bug trackers.  Just throw "Fixes 
#6596" into the commit message.  These will probably work if a more 
serious tool is adopted, too.

-Update src/tools/git_changelog to understand these messages and produce 
a delimited file about every bug fix discovered.  Import new entries 
into another table with the bug id as the foreign key.

-Provide a command line tool to change bug state, basically a thin 
wrapper around an UPDATE statement.  Make it easy to change ranges that 
are currently "Unconfirmed" to "Not a bug", for the bug reports that 
weren't really bugs.

-When point release tagging happens, run another script that looks for 
bug fix commits since the last one, and then save that version number 
into a "fixed in" table.

-Generate a web page out of the database.

I think I've outlined that in a way that would make useful steps toward 
adopting one of the full packages, too.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Don't override arguments set via options with positional argumen
Next
From: Tom Lane
Date:
Subject: Re: Bug tracker tool we need