Message-ID: <4042660D.4030301@dunslane.net>
Date: Sun, 29 Feb 2004 17:22:05 -0500
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org, pgsql-www@postgresql.org
Subject: Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
References: <200402260912.54001.josh@agliodbs.com>
	<200402271531.14964.josh@agliodbs.com>
	<20040227201416.N7999@cookie.varlena.com>
	<200402291211.33958.josh@agliodbs.com> <404258E9.10800@samurai.com>
In-Reply-To: <404258E9.10800@samurai.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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