Re: [sup-talk] Choosing a bug tracker for Sup

From: Daemian Mack <daemianmack@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Choosing a bug tracker for Sup
Date: Tue, 03 Nov 2009 12:03:38 -0500	[thread overview]
Message-ID: <1257266599-sup-1535@lenin> (raw)
In-Reply-To: <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>

Excerpts from Sebastian Schwarz's message of Tue Nov 03 11:20:47 -0500 2009:
> > RT doesn't come with a formal, formatted users or administrators
> > guide, but it's likely most of what you need to know to use and run it
> > is contained somewhere within this wiki, so look around a little, be
> > patient... and try not to install RT on a Sunday night when you need
> > to run it in production on Monday: it's big, and learning how to set
> > it up can take some time.
> 
> Can anyone with more experience with RT comment on this?

Having evaluated RT3 for fairly-intense production use at a prior
job, I can't really say I'd recommend it for our use here. As an
'enterprise-ready' solution, it's a bit ungainly out of the box, and
the bulk of its feature-set would probably be overkill for sup's
needs. It makes heavy use of the 'departmental queue' model whereby
many departments, consisting each of many employees, have some
permission set for many queues. Customization was a bit opaque (though
perhaps less so if you're very familiar with Perl), and though there's
an O'Reilly book for RT, I found it often fell short of my needs.

I'd suspect, with the glut of ticket-tracker software available,
there's something a good deal better-suited for sup out there. I'll
chime in again if I manage to find something that seems helpful.
-- 
http://daemianmack.com/

_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk