Re: Collaboration Tool Proposal -- Summary to date

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Collaboration Tool Proposal -- Summary to date
Дата
Msg-id 4042660D.4030301@dunslane.net
обсуждение исходный текст
Ответ на Re: Collaboration Tool Proposal -- Summary to date  (Neil Conway <neilc@samurai.com>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Collaboration Tool Proposal -- Summary to date
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Tablespaces