Re: Collaboration Tool Proposal -- Summary to date - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Collaboration Tool Proposal -- Summary to date
Date
Msg-id 4042660D.4030301@dunslane.net
Whole thread Raw
In response to Re: Collaboration Tool Proposal -- Summary to date  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers

Neil Conway wrote:

> Josh Berkus wrote:
>
>> D. One possible reservation may be integrating RT with GForge.
>
>
> I'm confused. Are we considering moving core backend development over
> to GForge as well, or just GBorg? (Personally the former doesn't
> strike me as a good idea, at least initially.)


You are correct that this has (quite annoyingly) been overlooked in much
of the discussion. Indeed, the needs of a GBorg project might well
differ both from the core project and from other GBorg projects. ISTM
the sensible thing right now would be to work on migrating GBorg and
leave the core project exactly as it is. OTOH, there was considerable
discussion a few months ago about bug tracking for the core project, and
we have unfortunately largely repeated that discussion with similar
results (for cheese in my_favourite_bugtrackers print "I like
$cheese\n"; ). I think that a careful choice made for GBorg might allow
us to progress the matter for the core project at a later stage, and the
choice should be made with that possible suitability in mind.

>
>
>> I think that the PostgreSQL project would be very much sending the
>> wrong message to use an effectively non-Postgres tool.
>
>
> Frankly, I think the PostgreSQL project would be sending "the wrong
> message" if we chose our tools on any basis other than functionality.
> We ought to use what works, whether it supports PG or not. Whether the
> bug tracker tool uses PostgreSQL, flat files or MS Access to store
> data is entirely secondary to whether it serves the needs of the
> development group.
>

The big issue is not going to be the bug tracker iteself, but how easy
it is to glue it to GForge (and if it requires too much customised glue
we really won't be making an advance at all). On those grounds alone a
FOSS bug tracker surely is preferable, regardless of political
considerations. Apart from the fact that its DB Schema lacks all
referential integrity constraints - a legacy of its origin in
you-know-what -  RT doesn't look half bad.

If we wanted to step outside the FOSS world, I don't think bug tracking
would be the area where there might be most need, but maybe that's just
me ;-)

cheers

andrew



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Collaboration Tool Proposal -- Summary to date
Next
From: Josh Berkus
Date:
Subject: Re: Tablespaces