might be what you're after. It's a bit bizarro, but it's effective and excessively featureful. It's geared mostly at user support, though. I've been using it for ~1.5 years now at two jobs (UNC Physics and ibiblio, both user-support-heavy), and have been pretty happy with it.
2005-05-10 06:04 am (UTC)
Oh yeah, I always hear great things about RT, but I've never tried it. Reading the site now....
Looking good! I see:
A powerful new command-line interface that allows power users to quickly and easily work with RT, even if they're out of the office is currently available for testing by the public.
I'll play with it tomorrow. Thanks!
Yeah I use RT daily as well. we tend to use it for much more granular and short tasks than is normal I guess, but it seems to hold up fine. Lately when it seems there's something new we want to track, the easiest solution is to just add another queue to RT. I think the only gripes we ever had with it were options that were missing because we hadn't upgraded to version 3 yet, which we did later. I don't know the backend much, but I've used it quite a bit. If you have any questions, shoot.
2005-05-10 08:17 am (UTC)
I also use RT and would recommend at least looking at it. The initial configuration can be fairly tricky if you're exposing it to external users, but if you just use it internally then it's not too bad -- if a little ugly -- out of the box. (I've even started using it to track some of my own todos that no one else needs to interact with.)
Another possibility might be debbugs, which is based on the Debian Bug Tracking System. IIRC it has an email-based interface that can be used to control things (Debian's Bug Tracking System certainly does, and the maintainers use it to great effect).
IIRC both of them will support tracking dependencies.
Seconded. Our need for RT has been trumped by a corporate move to SAP, but it'd be the first place I'd look if I needed something like that. I suspect that obra
would be happy to give you the pitch if you want to check features/functionality, too -- RT is his baby.
We've had nothing but trouble with RT. Apparently a P4 with 1G of ram isn't enough to run an issue tracker. I don't know why everybody likes it so much; the interface is horrible, the software was written by an amateur, and it doesn't scale at all.
2005-05-10 06:04 am (UTC)
I'll kick your ass tomorrow in person.
2005-05-10 07:13 am (UTC)
is even easier -- no complicated POSTs, only gets -- especially convenient if you wanna, e.g., quickly delete your todo items!
2005-05-10 07:14 am (UTC)
2005-05-10 07:17 am (UTC)
Another one you might want to check out is Eventum from MySQL AB. You might have already even used it with their Support system (it is what they use).
It has a command-line interface and also a defined XML-RPC and SOAP interface to the system as well.
http://dev.mysql.com/downloads/other/eventum/index.html is a link to more information.
Maybe try using Trac
, it should not be too hard to control it from the commandline (especially in the trunk 0.9.pre version).
We're working on an XML-RPC interface for the next version of Bugzilla.
Actually, I was working on getting together a bunch of bugtrackers to try to define a standard set of function calls that could be used in such an interface, but the two that I spoke with said they thought it wasn't possible. I'm still planning to try, though, once we get out of development freeze for Bugzilla.
Anyhow, the current code is up at:https://bugzilla.mozilla.org/show_bug.cgi?id=224577
And the Red Hat Bugzilla already has the XML-RPC interface in it, although it may not be the same interface we eventually decide on.
2005-05-10 05:08 pm (UTC)
I don't think Mantis
has a command-line tool, but it's probably worth checking into because it's pretty great in every other way. It's based on pretty straightforward MySQL, so it's pretty easy to reach in and mess with the db directly.
There's a project called MantisConnect that provides an interface. I know this because the guy who writes scmbug (a practically-standard "version-tracking-to-bug-tracking interface") uses it for that, and he pointed me at it when I was thinking about getting together with the Mantis folks to come up with some standard XML-RPC interface.
2005-05-11 03:37 pm (UTC)
Yeah. Right now, he (Kristis Makris, who writes it) is my primary encouragement to work on the XML-RPC interface, since he needs it very much, and he has a well-defined set of API functions he needs. :-)
Of course, I think the bug-buddy people would also appreciate it. :-)
I hear that overall scmbug works really well. And it's under highly active development.
2005-05-23 06:38 pm (UTC)
Just to clarify, we don't use MantisConnect for the Mantis integration, but the Perl DBI to directly connect to Mantis' DB. But that's really why your XML-RPC interface is needed: so we won't have to do that, and so when the Mantis DB schema changes the integration won't break. When the schema changes, probably the XML-RPC interface also changes and must have been updated.
Offtopic: dude, you broke cpanplus. :)))
CPAN Terminal> install HTML::Mason
Checking if source files are up to date
Updating source file '01mailrc.txt.gz'
Trying to get /pub/CPAN/authors/01mailrc.txt.gz from carroll.cac.psu.edu via ftp
Updating source file '02packages.details.txt.gz'
Trying to get /pub/CPAN/modules/02packages.details.txt.gz from carroll.cac.psu.edu via ftp
Updating source file '03modlist.data.gz'
Trying to get /pub/CPAN/modules/03modlist.data.gz from carroll.cac.psu.edu via ftp
Running [/bin/gzip -cdf /root/.cpanplus/01mailrc.txt.gz]...
Running [/bin/gzip -cdf /root/.cpanplus/03modlist.data.gz]...
Backslash found where operator expected at (eval 46) line 1, near "v\"
Error in eval of dslip source files: syntax error at (eval 46) line 1, near "v\"
in CPANPLUS::Internals::Source::_create_dslip_tree at Wed May 11 18:01:43 2005 at /opt/perl/lib/perl5/site_perl/5.8.5/CPANPLUS/Internals/Source.pm line 312
String found where operator expected at (eval 47) line 2, near ")',
(Might be a runaway multi-line '' string starting on line 1)
(Missing operator before ',
Error in eval of dslip source files: Bad name after BRADFITZ' at (eval 47) line 2.
in CPANPLUS::Internals::Source::_create_dslip_tree at Wed May 11 18:01:43 2005 at /opt/perl/lib/perl5/site_perl/5.8.5/CPANPLUS/Internals/Source.pm line 315
2005-05-11 11:05 pm (UTC)
WTF? I've never touched Mason.
No, I'm not blaming you. It was just funny that cpanplus broke somewhere and showed your name. Relax. :)
2005-05-12 12:07 am (UTC)
I figured it was something like. Still... wonder why my name was anywhere near that. :-)