Re: Collaboration Tool Proposal -- Summary to date - Mailing list pgsql-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