Re: Bug tracker tool we need

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jay Levitt <jay(dot)levitt(at)gmail(dot)com>, Greg Smith <greg(at)2ndQuadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, 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>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug tracker tool we need
Date: 2012-04-18 17:17:37
Message-ID: 4F8EF731.80702@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/17/2012 11:29 PM, Andrew Dunstan wrote:
>
>
> On 04/17/2012 04:38 PM, Tom Lane wrote:
>> Jay Levitt<jay(dot)levitt(at)gmail(dot)com> writes:
>>> Greg Smith wrote:
>>>> Tracking when and how a bug is backported to older versions is one
>>>> hard part
>>>> of the problem here.
>>> That's a great point. Both GitHub and git itself have no real concept of
>>> releases, and can't tell you when a commit made it in.
>> We do actually have a somewhat-workable solution for that, see
>> src/tools/git_changelog. It relies on cooperation of the committers
>> to commit related patches with the same commit message and more or
>> less the same commit time, but that fits fairly well with our practices
>> anyway. If we did have an issue tracker I could see expecting commit
>> messages to include a reference to the issue number, and then it would
>> not be hard to adapt this program to key on that instead of matching
>> commit message texts.
>>
>>
>
>
> Yeah, that would be good.
>
> BTW, since we're discussing trackers yet again, let me put in a plug for
> Bugzilla, which has mature Postgres support, is written in Perl (which a
> large number of hackers are familiar with and which we use extensively),
> has a long history and a large organization behind it (Mozilla) and last
> but not least has out of the box support for creating updating and
> closing bugs via email (I just set up an instance of the latest release
> with this enabled to assure myself that it works, and it does.) It also
> has XML-RPC and JSON-RPC interfaces, as well as standard browser
> support, although I have not tested the RPC interfaces.

years ago when I did the PoC install for PostgreSQL i used the
RPC-Interface for replacing the bug-reporting form on the main website,
it was prett ylimited back then (especially around authentication and a
way to actually make the report show up with the reporters name (which
very likely does not have a BZ account), but all those were solvable. BZ
really has the drawback that it is kind of a monster on the featureside
and you need to invest some significant time to make the UI
understandable before you can actually present it to a wider audience.

Stefan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-04-18 17:26:35 Re: Bug tracker tool we need
Previous Message Christopher Browne 2012-04-18 17:16:25 Re: Bug tracker tool we need