5 ms·

Yet another (command-line) bug tracker

49 points by jeremyjitr 16y ago

kilian 16y ago
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.
- bigfudge 16y ago
  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.
  - bigfudge 16y ago
    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.
    - beza1e1 16y ago
      Interesting idea. One could do that in ~/dev and see all issues of all projects inside...
    - beza1e1 16y ago
      I just committed a plugin, which implements this: http://github.com/beza1e1/later/commit/4d4660124e008590618362bfe97d832b6a25c6e1 http://github.com/beza1e1/later/commit/4d4660124e00859061836...
c1sc0 16y ago
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.
- beza1e1 16y ago
  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
  - mattyb 16y ago
    Why should all discussion happen on the mailing list?
    - jrockway 16y ago
      Why shouldn't it?
      - Zev 16y ago
        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?
yummyfajitas 16y ago
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.
- jamesbritt 16y ago
  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.
- agentultra 16y ago
  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 http://code.google.com/p/tracshell
- StavrosK 16y ago
  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.
- jrockway 16y ago
  Sounds like you want SD: http://syncwith.us/ 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.
mkramlich 16y ago
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.

49 points by jeremyjitr 16y ago

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.

bigfudge 16y ago
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.
- bigfudge 16y ago
  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.
  - beza1e1 16y ago
    Interesting idea. One could do that in ~/dev and see all issues of all projects inside...
  - beza1e1 16y ago
    I just committed a plugin, which implements this: http://github.com/beza1e1/later/commit/4d4660124e008590618362bfe97d832b6a25c6e1 http://github.com/beza1e1/later/commit/4d4660124e00859061836...

c1sc0 16y ago

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.

beza1e1 16y ago
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
- mattyb 16y ago
  Why should all discussion happen on the mailing list?
  - jrockway 16y ago
    Why shouldn't it?
    - Zev 16y ago
      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?

yummyfajitas 16y ago

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.

jamesbritt 16y ago
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.
agentultra 16y ago
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 http://code.google.com/p/tracshell
StavrosK 16y ago
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.
jrockway 16y ago
Sounds like you want SD: http://syncwith.us/ 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.

mkramlich 16y ago

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.