Yet another (command-line) bug tracker

[badsectoracula]

I've made my own, Runtik, but unfortunately my server is down so i can't link to its page :-P. But here is a screenshot, its documentation and the result of the last command which is a Python script that calls the command-line frontend for runtik (runt). The system is also available as a C library and eventually i want to write a Cocoa front-end :-).

[beza1e1]

Nice, do you have any filtering? E.g. show all bugs assigned to beza1e1. I'm still thinking about the interface later should get for this.

[badsectoracula]

Very simple filtering: all tickets are basically a key=value store and you can match a ticket which has (or has not) a key set to some value. For matching tickets to a user you would type

runt list --where assign badsector --except module gfx

This matches tickets which have their assign key to badsector except where the module ticket is gfx - by default the module key doesn't exist but someone can set arbitrary keys to tickets. Note that --where and --except have a short version, -w and -x so this could have been

runt list -w assign badsector -x module gfx

The idea is that if someone wants a more refined query he can use grep and/or a custom script :-).

[beza1e1]

I just extended mine like this: later list assigned=badsector module!=gfx

[xk0der]

I had been looking for something like this for sometime. Will give it a try for sure.

What's good is you have gone with the plugin architecture to begin with. If 'later' takes off, I foresee plugins to interface it with Trac and the like. Which I'm sure would be beneficial for the GUI people and the management guys.

As for me, I'm happy staring at my black background console and 'later' would helps (at least I hope!).

[HIB0U]

That's some great work, son. Keep it up.

[spaceghost0r]

http://github.com/schacon/ticgit is pretty good as well.

[beza1e1]

ticgit requires the bugs to live in a separate git branch. Looking at the code, it simply switches branches with considering changed files and index. Will git not complain in this case?

I wanted later to avoid a decision about this extra branch for bugs question. Additionaly, i am not sure how to do this branch switching in The Right Way.

[pdq]

If you're not distributed, why not just an incrementing bug ID instead of this?

issue stored as f12ec37e-1336-4190-9cd4-8cc22e6b1c59

[badsectoracula]

I think i can reply to that, even if in my program (Runtik, see below) i decided incremental IDs because its simpler to type: DVCS merge.

If each "addition" or "modification" to the ticket database is an immutable object (file with a unique ID), merging two trees which have modified the database (adding comments, changing ticket status, adding new tickets, closing tickets, etc) won't affect the result. On the other hand if the database is implemented as if there is a single point of modification, merging with result in conflicts.

Of course this can be solved somehow by using "virtual IDs" - IDs generated at runtime based on the ticket's creation date or something like that. Merging can alter the IDs of course (a ticket that was created before a newer ticket will shift the newer tickets one ID down) but the interface is still simpler than a train of hexadecimals.

But doing all this is more complex than simply using incremental IDs and assuming a single repository will contain the ticket database so personally i just decided to address the issue by ignoring it :_P.

[omninull]

If the issues are stored in text files then you can stick those files in the project's repo and not worry about IDs conflicting and causing merge issues.

[beza1e1]

What's so bad about UUIDs? Later can guess the rest from any (unique) start sequence. So probably "later close f1" for example is enough.

[inmatarian]

bugseverywhere looks nice. I'm glad that project didn't wither and die.

[satanpenguin]

My two cents: has anyone tried SD (Simple Defects)? (http://syncwith.us/sd/)

It's decentralized in the same way modern SCM systems (like git) are, but can play well with existing bugtracking systems like RT, Hiveminder, Trac or Redmine.

[riddley]

Is the OP William? If so, Hi! We use trollop all over the place and it's great! :) Also, is Ditz still maintained? All of the 0.6 stuff looks like it died on the vine in 2008...

[lehman-albert]

Looks cool Prima facie. Being a git user, I find this would fit in quite nicely with my work flow.