> 
> My apologies, then!   I was operating off of the statements 
> of others, and the 
> fact that the only RT impelementations I've used were running 
> on MySQL.   So, 
> questions:
> 
> 1) can you compare/contrast RT vs. BZ vs. Simplified 
> bug-tracking, like 
> GForge?

I've used Bugzilla for searching for FOP issues, and a couple other places,
and I find the RT search much more obvious. I can get what I want out of
Bugzilla, but usually by creating a really broad search and sifting entries
one at a time for likely candidates. The fact that an RT search is iterative
is much more obvious, because the bottom of the search page lists all of the
current criteria, and the box for adding new ones. Add or remove, and re-run
the search. I like the trick that it does with mutually exclusive
conditions: It assumes an 'or' between them. (eg, all tickets that are in
state 'open' or 'closed'.) 

OTOH, Bugzilla tracks a whole pile more fields by default. I've taken to
putting version numbers in the ticket subject in RT because for the small
project here, it's easier than learning how to add a version field. (I
haven't tried adding my own fields.) 

Both handle attachments and comments sanely. I don't know if BZ has an
e-mail interface, but the one in RT has filled the basic needs here. (We
haven't pushed the limits of the e-mail part.)

I have never tried to install BZ. RT's install (RedHat 8.0, PostgreSQL 7.2.4
from RPMs) was straightforward once all the Perl modules were up to date.
(All of the needed modules were available from CPAN.)

I don't recall using any simplified bug tracking on-line, except maybe at
ImageMagick.com, which seems to be more a forum or mailing list search, with
no real tracking fields.

> 
> 2) What help, if any, would we be able to get in supporting 
> RT from the RT 
> community?

I'm afraid I have no idea what or where the larger RT community is. I know
there's commercial support available from the author (whom I have no contact
with), and I found the answers to my (self-created) problems during setup
using Google. I found RT because of a (don't ban me, please ;-) discussion
on SlashDot. (http://slashdot.org/article.pl?sid=03/10/06/1854211) There
were a large number of proponents of RT there; their posts claimed years of
use at many sites. 

I would be happy to lend my meager talents to setting it up for a trial, if
that's where the group decides to go.

But Josh made a good point off-list: are we trying to solve the problem of
ticket/bug tracking, or community/collaboration in general? 

My $0.02: CVS handles the code, mailing lists handle the dialog, and a
ticket/bug tracker keeps people from losing things. About all that leaves
for the web site to do is advocate PostgreSQL (which I think it does nicely)
and related projects, and provide some glue (like how to find the name of
the other lists or projects to see what they're doing.) New tools or old,
every day with PostgreSQL is a good day. 



Fri, 27 Feb 2004 14:49:10 -0500
"Bort, Paul" <pbort@tmwsystems.com>
Re: [HACKERS] Collaboration Tool Proposal


Bort, Paul wrote:

>>My apologies, then!   I was operating off of the statements 
>>of others, and the 
>>fact that the only RT impelementations I've used were running 
>>on MySQL.   So, 
>>questions:
>>
>>1) can you compare/contrast RT vs. BZ vs. Simplified 
>>bug-tracking, like 
>>GForge?
>>    
>>
>
>I've used Bugzilla for searching for FOP issues, and a couple other places,
>and I find the RT search much more obvious. I can get what I want out of
>Bugzilla, but usually by creating a really broad search and sifting entries
>one at a time for likely candidates. The fact that an RT search is iterative
>is much more obvious, because the bottom of the search page lists all of the
>current criteria, and the box for adding new ones. Add or remove, and re-run
>the search. I like the trick that it does with mutually exclusive
>conditions: It assumes an 'or' between them. (eg, all tickets that are in
>state 'open' or 'closed'.) 
>
>OTOH, Bugzilla tracks a whole pile more fields by default. I've taken to
>putting version numbers in the ticket subject in RT because for the small
>project here, it's easier than learning how to add a version field. (I
>haven't tried adding my own fields.) 
>
>Both handle attachments and comments sanely. I don't know if BZ has an
>e-mail interface, but the one in RT has filled the basic needs here. (We
>haven't pushed the limits of the e-mail part.)
>
>I have never tried to install BZ. RT's install (RedHat 8.0, PostgreSQL 7.2.4
>from RPMs) was straightforward once all the Perl modules were up to date.
>(All of the needed modules were available from CPAN.)
>
>I don't recall using any simplified bug tracking on-line, except maybe at
>ImageMagick.com, which seems to be more a forum or mailing list search, with
>no real tracking fields.
>
>  
>
>>2) What help, if any, would we be able to get in supporting 
>>RT from the RT 
>>community?
>>    
>>
>
>I'm afraid I have no idea what or where the larger RT community is. I know
>there's commercial support available from the author (whom I have no contact
>with), and I found the answers to my (self-created) problems during setup
>using Google. I found RT because of a (don't ban me, please ;-) discussion
>on SlashDot. (http://slashdot.org/article.pl?sid=03/10/06/1854211) There
>were a large number of proponents of RT there; their posts claimed years of
>use at many sites. 
>

[some stuff about RT]

FWIW there's a good directory of bug tracking systems on google: 
http://directory.google.com/Top/Computers/Software/Configuration_Management/Bug_Tracking/Free/

I have looked at RT briefly today, and its technology appears to be 
sound. (Just the fact that it will run under both mod_perl and FastCGI 
means that a lot of common insanity is missing - these environments are 
very good at blowing up with badly written software. They are also far 
more scalable than standard CGI web environments, so we would be less 
likely to have performance issues.)

>
>I would be happy to lend my meager talents to setting it up for a trial, if
>that's where the group decides to go.
>

ditto

>
>But Josh made a good point off-list: are we trying to solve the problem of
>ticket/bug tracking, or community/collaboration in general? 
>

The discussion arose in the context of an alternative to the rather 
simple bug tracking system that comes with GForge. The biggest issue 
with any replacement would be to plug it in successfully. If too much 
glue is needed, we haven't really made an advance on the current GBorg 
code base.

cheers

andrew




Fri, 27 Feb 2004 19:47:30 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] Collaboration Tool Proposal