Re: Bug tracker tool we need

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Jay Levitt <jay(dot)levitt(at)gmail(dot)com>, Alex <ash(at)commandprompt(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug tracker tool we need
Date: 2012-04-18 03:23:00
Message-ID: 4F8E3394.5040801@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-04-18 03:44:11 Re: Bug tracker tool we need
Previous Message Robert Haas 2012-04-18 03:22:56 Re: Re: [COMMITTERS] pgsql: Don't override arguments set via options with positional argumen