Log in

No account? Create an account
command-line bug/todo/issue tracking - brad's life — LiveJournal [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

command-line bug/todo/issue tracking [May. 9th, 2005|10:50 pm]
Brad Fitzpatrick
[Tags|, ]

Is there a good bug/todo/issue tracking system that does both of:

-- stable, defined API for external clients to use. No, not just doing an HTTP POST to the parameters that the current version happens to use, and then screen-scraping the HTML result.

-- dependencies Bugzilla has these. FogBogz doesn't, I hear. But then FogBugz doesn't have an API either.

That's all I want. Then I can do little command-line apps to add items, add dependencies, list my things, move jobs between people, etc. And edit my entire to-do list in $EDITOR and sync it with "minitask sync" or something.

I find typical issue tracking systems way too heavy. I can't use FogBugz or Bugzilla for most my stuff because I add/remove small items (to my scraps of paper) too quickly. But I don't want to use scraps of paper. And I want to be able to throw items from my scraps of paper to others.

If this mythical system I dream of did have a web interface (and it should, for people who like those sorts of things), it'd just be a consumer of the API, and not hit the database (be it a database, svn, flat files) itself at all. It could be a 100 line perl *.cgi file for all I care, and it'd be plenty fast.

What am I looking for? This project's too boring to write.

[User Picture]From: xaosenkosmos
2005-05-10 06:01 am (UTC)
RT 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.
(Reply) (Thread)
[User Picture]From: brad
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!
(Reply) (Parent) (Thread)
[User Picture]From: chris
2005-05-10 08:40 am (UTC)
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.
(Reply) (Parent) (Thread)
[User Picture]From: edm
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.

(Reply) (Parent) (Thread)
[User Picture]From: mendel
2005-05-10 01:57 pm (UTC)
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.
(Reply) (Parent) (Thread)
From: divelog
2005-05-10 06:55 pm (UTC)

RT Blows

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.
(Reply) (Parent) (Thread)
(Deleted comment)
[User Picture]From: brad
2005-05-10 06:04 am (UTC)
I'll kick your ass tomorrow in person.
(Reply) (Parent) (Thread)
[User Picture]From: funjon
2005-05-10 06:38 am (UTC)
Ugh. Want help?
(Reply) (Parent) (Thread)
From: evan
2005-05-10 07:13 am (UTC)
http://www.backpackit.com/ is even easier -- no complicated POSTs, only gets -- especially convenient if you wanna, e.g., quickly delete your todo items!
(Reply) (Thread)
[User Picture]From: brad
2005-05-10 07:14 am (UTC)

Check out Jesse's BLOG post about that:

(Reply) (Parent) (Thread)
From: (Anonymous)
2005-05-10 07:17 am (UTC)

Check-out Eventum

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.
(Reply) (Thread)
From: manuzhai
2005-05-10 08:42 am (UTC)
Maybe try using Trac, it should not be too hard to control it from the commandline (especially in the trunk 0.9.pre version).
(Reply) (Thread)
[User Picture]From: avatraxiom
2005-05-10 05:01 pm (UTC)
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:


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.

(Reply) (Thread)
[User Picture]From: brad
2005-05-10 05:08 pm (UTC)
(Reply) (Parent) (Thread)
[User Picture]From: bitwise
2005-05-10 05:54 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.
(Reply) (Thread)
[User Picture]From: avatraxiom
2005-05-11 03:20 am (UTC)
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.

(Reply) (Parent) (Thread)
[User Picture]From: brad
2005-05-11 03:37 pm (UTC)
scmbug: interesting!
(Reply) (Parent) (Thread)
[User Picture]From: avatraxiom
2005-05-11 07:59 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.

(Reply) (Parent) (Thread)
From: (Anonymous)
2005-05-23 06:38 pm (UTC)


Hi Max.

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.

(Reply) (Parent) (Thread)
[User Picture]From: simonff
2005-05-11 10:04 pm (UTC)
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
(Reply) (Thread)
[User Picture]From: brad
2005-05-11 11:05 pm (UTC)
WTF? I've never touched Mason.
(Reply) (Parent) (Thread)
[User Picture]From: simonff
2005-05-11 11:33 pm (UTC)
No, I'm not blaming you. It was just funny that cpanplus broke somewhere and showed your name. Relax. :)
(Reply) (Parent) (Thread)
[User Picture]From: brad
2005-05-12 12:07 am (UTC)
I figured it was something like. Still... wonder why my name was anywhere near that. :-)
(Reply) (Parent) (Thread)