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

On Wed, Apr 18, 2012 at 19:17, Stefan Kaltenbrunner
<stefan@kaltenbrunner.cc> wrote:
> On 04/17/2012 11:29 PM, Andrew Dunstan wrote:
>>
>>
>> On 04/17/2012 04:38 PM, Tom Lane wrote:
>>> Jay Levitt<jay.levitt@gmail.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.

What I saw from it, it would take more time and work to make the UI
understandable and workable, and to get it to adapt to *our* process
and workflow than to design a whole new tool from scratch...

The problem I've found with most tools is that they work reasonably
well if you let them control the entire workflow. But when you want to
do things your own way, and it doesn't match up with what they were
originally designed to do, it all comes falling down quickly...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/