Yet another (command-line) bug tracker | Hacker News Reader

Yet another (command-line) bug tracker

beza1e1.tuxen.de

49 pointsjeremyjitr16 comments

I don't think we need another bug tracker - bugzilla and trac do a great job already.

What I'd love to have is a command line interface to existing bug trackers.

Some years ago I wrote one (cleverly named Tracuala) for trac. It was good enough most of the time for my needs. Trouble was, Trac didn't have a real Web API at the time, so I was hacking around cookies and authentication and what not. And when I upgraded a Trac instance, stuff broke.

Nowadays I use Pivotal Tracker, which has a very nice Web API. That allowed me to write yet another CLI tool (cleverly named Pivotal Slacker) which works quite nicely for fetching lists of stories, adding new stories, doing bulk updates or additions from yaml files, and the like.

The upshot is that all Web-based tools should try to offer a decent RESTful API as well so that folks who want additional tools can add them without having to worry about coding to the quirks of Web page scrapping.

I wrote one a while ago on a whim for the same thing. It's called TracShell. It's a command-line interface for Trac using the Trac XML-RPC plugin.

It could use some love as contributions have dropped off and I haven't had time to maintain it myself for quite a while.

However, it is quite useable.

http://code.google.com/p/tracshell

You've never used Redmine, I see!

Not that there's anything wrong with the other two, but Redmine is miles ahead, in my opinion.

Sounds like you want SD:

http://syncwith.us/

It syncs with various online bug trackers and supports full offline manipulation of the bugs. I would use it if I didn't just make a list of stuff to do in a text file.

So, something that's not immediatelly apparent upon reading this. How do I use it? Do I init it in an existing GIT repository and will the added bugs be synced along with my other changes? That would be awesome to replace my current method of light-weight bug tracking: a todo.txt in the git repo.

When you init it, it creates a .later directory to store the issues. You could revision this along with code, so yes it seems like a nice replacement to the todo.txt.

Playing a bit more, what would be really nice would be to be able to do later -r list to recurse through subdirectories listing issues in those too. At present it only looks upwards.

Interesting idea. One could do that in ~/dev and see all issues of all projects inside...

I just committed a plugin, which implements this: http://github.com/beza1e1/later/commit/4d4660124e00859061836...

I'm just wondering: is using a command-line bug editor actually a good idea? Seems like the perfect way to stay out of touch with how normal people experience your software.

Stolen from ditz:

- create a simple website form for bug reports, which emails to the project mailing list, where all discussion should happen anyways

- let a bot scan the mailing list for bug reports and commit them, wherever suited

Why should all discussion happen on the mailing list?

Why shouldn't it?

As long as its easy to hack up a script to parse the output of the discussion, what difference does it really make where the discussion happens?

A CLI bug tracker client is attractive if the data model is super simple and/or pure text. Once you need or want to start attaching files, especially screenshots or other media, to each issue, then the CLI doesn't fit as well. Very appealing idea, however.

Reply on news.ycombinator.com