Re: [HACKERS] Collaboration Tool Proposal -- Summary to date

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-hackers(at)postgresql(dot)org, pgsql-www(at)postgresql(dot)org
Subject: Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
Date: 2004-02-29 22:22:05
Message-ID: 4042660D.4030301@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-hackers-win32 pgsql-www

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

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Marc G. Fournier 2004-02-29 22:31:48 Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
Previous Message Josh Berkus 2004-02-29 21:49:06 Re: [HACKERS] Collaboration Tool Proposal -- Summary to date

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2004-02-29 22:27:21 Re: Tablespaces
Previous Message Josh Berkus 2004-02-29 21:49:06 Re: [HACKERS] Collaboration Tool Proposal -- Summary to date

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Marc G. Fournier 2004-02-29 22:31:48 Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
Previous Message Josh Berkus 2004-02-29 21:49:06 Re: [HACKERS] Collaboration Tool Proposal -- Summary to date

Browse pgsql-www by date

  From Date Subject
Next Message Marc G. Fournier 2004-02-29 22:31:48 Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
Previous Message Josh Berkus 2004-02-29 21:49:06 Re: [HACKERS] Collaboration Tool Proposal -- Summary to date