Skip site navigation (1) Skip section navigation (2)

Re: Collaboration Tool Proposal -- Summary to date

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: pgsql-www(at)postgresql(dot)org
Subject: Re: Collaboration Tool Proposal -- Summary to date
Date: 2004-02-29 20:11:33
Message-ID: 200402291211.33958.josh@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackerspgsql-hackers-win32pgsql-www
Folks,

I thought that I would give everyone a summary of the current discussion of 
collaboration tools and bug-trackers for our project as I read them.   I 
think that we are quite close to a consensus.   Please comment if I've missed 
something.

GBorg-->GForge migration:  so far, nobody has objected to this idea, except 
for justifiable caution about the resources required.    If the conversion 
can be accomplished relatively seamlessly, and/or through outside help, I 
don't think we have any reason NOT to proceed with a *gradual* migration.

BugTrackers:  here, opinion is more divided.   Many people seem to feel that 
they would like bug trackers more sophisticated than those offered by the 
built-in GForge tool.    The criteria that seem to have general consensus 
are:
A. The bug tracker should have some kind of e-mail interface which allows 
responding to bugs a well as tracking them, so that people who don't like web 
interfaces don't need to use them.
B.  The bug tracker must be OSS; proprietary software is too risky when there 
are alternatives.
C. The bug tracker must use PostgreSQL, and it would be preferable if 
PostgreSQL support was available in the default branch of the project.

And I will add one that I see as unavoidable, even though it's been sort of 
glossed over in the discussions:
D. The bug tracker should not require extensive customization or other work by 
our team, becuase we simply don't have the people.

Based on this, I will evaluate the various bug trackers which have been 
mentioned to date:

GForge's Tracker:  This choice has the tremendous benefit of already being 
built-in to GForge and thus integrated with the rest of the project 
infrastructure.   On the rest of the criteria:
A. GF-Tr does not support e-mail interaction at all.
B. pass
C. pass
D. pass
Otherwise, GF-Tr's other detraction is that it is relatively unsophisticated, 
not supporting, for example, tying bugs to version numbers.  This simplicity 
can also be an asset as far as start-up time is concerned, though, but there 
exists the danger that newbies would use the tracker while developers 
continute to use e-mail. making the system ineffective.

BugZilla:  This has been a popular suggestion because lots of people are 
familiar with it.   However, BZ fails our criteria on three counts:
A.  BZ does not support issue alterations by e-mail; in fact, you can't even 
log in by e-mail link.
B. Pass
C. BZ does not have any PG support in its default branch, and the RH port is 
currently unmaintained.   While a member of the BZ team is attempting to 
complete a port, there is no expected completion date.
D. Given C., we could reasonably expect that using BZ would require 
significant support from the PG community in order to maintain a PG port.  
Given that one of the goals of the migration is to *reduce* the resources 
required by our community to maintain our infrastructure, this seems unwise.
     There is also the factor that several people on this list hate BZ's 
interface with a passion not expressed for other possible tools. I am one of 
them, I'm afraid, and since I am the primary volunteer for admining the 
system, I think my opinion carries some weight.   I find the BZ interface 
baffling, cumbersome, inefficient, and difficult to learn.

Jira:   While I have not actually tested it, this is known as a very 
sophisticated, professional enterprise-grade bug tracker.  The commercial 
developers are PostgreSQL supporters and have offered us this option as their 
support for our project, for which we are greatful.
A.  Pass
B.  Jira is unfortunately not OSS, meaning that we would be 100% dependant on 
the management policy of Alessian corp. for our use of it.   I am not 
comfortable with this idea, nor is Core, nor several other people.
C. Pass
D. Pass
There is the further issue that based on technical requirements Jira might 
have to the eternally hosted to postgresql.org, making it difficult to 
integrate it into the rest of our operations.

Request Tracker:  perl.org's issue tracker has grown quite sophisticated and 
added PostgreSQL support.
A. Pass -- RT supports commenting on, and modifying, bugs by e-mail, as well 
as running e-mail "scripts" on creation or alteration of bugs.
B. Pass
C. Pass -- PostgreSQL and MySQL are fully supported in version 3.
D. One possible reservation may be integrating RT with GForge.  Andrew D. and 
some of the GForge people will be checking on how troublesome this will be, 
and whether or not this might become a standard GForge option in the future.
       Overall, I personally am liking the new RT and seeing it as our best 
option for a bug-tracker which would genuinely improve the operations of our 
community.   One thing I'm really attracted to is the ability to create 
"personal list" so that I can put my personal core-member todo list online.

Roundup:  This was suggested by a couple of people, including Elein who is 
quite fond of it.   Per my perusing, however, there are several issues:
A.  Pass: roundup allows full interaction by e-mail.
B.  Pass
C.  Roundup was designed not to rely on a relational database.   See: http://
roundup.sourceforge.net/doc-0.6/overview.html#roundup-s-hyperdatabase
Like a lot of Zope tools, Roundup uses python objects for storage of data 
except between sessions.    Further, where Roundup does suggest databases for 
scalability, their recommendations do not include PostgreSQL.  While this is 
a perfectly valid design methodology according to certain criteria, I think 
that the PostgreSQL project would be very much sending the wrong message to 
use an effectively non-Postgres tool.
D. If there is a version of Roundup which supports PostgreSQL, it is not the 
default branch ... once again putting us in the same situation we would be in 
with BZ or are in with GBorg.

Other Tools:  The other bug tracking tools, OSS and otherwise, do not seem to 
be anywhere near as mature as the above options, making them not an 
enhancement to current issue processing.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


In response to

Responses

pgsql-www by date

Next:From: Marc G. FournierDate: 2004-02-29 20:53:01
Subject: Re: Collaboration Tool Proposal -- Summary to date
Previous:From: Justin CliftDate: 2004-02-29 18:50:05
Subject: Re: jdbc.postgresql.org still configured to send .jars

pgsql-advocacy by date

Next:From: Marc G. FournierDate: 2004-02-29 20:53:01
Subject: Re: Collaboration Tool Proposal -- Summary to date
Previous:From: V i s h a l Kashyap @ [Sai Hertz And Control Systems]Date: 2004-02-29 16:47:18
Subject: Re: [pgsql-www] Why not fork PHP.NET

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2004-02-29 20:53:01
Subject: Re: Collaboration Tool Proposal -- Summary to date
Previous:From: Andrew DunstanDate: 2004-02-29 19:20:19
Subject: Server Side PL support

pgsql-hackers-win32 by date

Next:From: Marc G. FournierDate: 2004-02-29 20:53:01
Subject: Re: Collaboration Tool Proposal -- Summary to date
Previous:From: V i s h a l Kashyap @ [Sai Hertz And Control Systems]Date: 2004-02-29 16:47:18
Subject: Re: [pgsql-www] Why not fork PHP.NET

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group