Currently i am developing a bug tracker and this documents my thought process of why and what.

Nowadays i tend to use git for everything. Writing a little LaTeX document means committing to a local git repository. A short git init and git commit -a -m "initial" is so easy, there is no reason not to do it. The nice git diff alone is valuable enough to justify the overhead, because after the lunch break i can dive into work faster. Additionally it is relaxing to know everything backed up and versioned in a repository.

Now where is a bug tracker that is as easy and unobtrusive as my little git tool? Command-line usage already weeds out all the web-based solutions like Bugzilla, Trac, FogBugz, or Mantis. Likewise hosted solutions.

ditz

One command-line bug tracker is ditz. I dislike ditz, because it is constantly nagging me with questions. Here an example session:

$ ditz init I wasn't able to find a configuration file ./.ditz-config. We'll set it up right now. Your name (enter for "Andreas Zwinkau"): Your email address (enter for "beza1e1@dhcppc1"): Directory to store issues state in (enter for "bugs"): Project name (enter for "test"): Issues can be tracked across the project as a whole, or the project can be split into components, and issues tracked separately for each component. Track issues separately for different components? (y/n): Track issues separately for different components? (y/n): n Ok, bugs directory created successfully. $ ditz add Title: flux compensator Description (ctrl-d, ., or /stop to stop, /edit to edit, /reset to reset): We need one Is this a (b)ugfix, a (f)eature, or a (t)ask? t Issue creator (enter for "Andreas Zwinkau <beza1e1@dhcppc1>"): Comments (ctrl-d, ., or /stop to stop, /edit to edit, /reset to reset): no comment Added issue test-1. You may have to inform your SCM that the following files have been added: bugs/issue-08f4205acae64135354e65264cb10462d95b6974.yaml

I feel like using a Microsoft Office wizard dialog. The git power user feeling is better. The development status of ditz, is "done", which is similiar to "dead", but with less bugs.

bugs everywhere

The alternative is bugs everywhere (in short "be".) A similar scenario like above, but much shorter.

$ be set-root Guessing id 'beza1e1 <beza1e1@dhcppc1>' No revision control detected. Directory initialized. $ be new "flux compensator" Guessing id 'beza1e1 <beza1e1@dhcppc1>' Guessing id 'beza1e1 <beza1e1@dhcppc1>' Created bug with ID bc9

Much more unobtrusive than ditz. But note that the documentation is outdated. be init only shows an unhelpful error message. So website and documentation feel quite unmaintained. At least, remove obsolete stuff!

Also i have some philosophical issues with be, therefore i wrote my own.

later

The usage is later is similar to be.

$ later init $ later add "flux compensator" issue stored as f12ec37e-1336-4190-9cd4-8cc22e6b1c59

The advantages of later are:

flexible plugin mechanism : Some things have no clear good solution. For example should a git-integrated tracker store issues with each branch or in a branch of its own? In other words: Are bugs branch or project specific? As long as there is no clear winner, the code belongs into a plugin, so the core application is flexible.

: Some things have no clear good solution. For example should a git-integrated tracker store issues with each branch or in a branch of its own? In other words: Are bugs branch or project specific? As long as there is no clear winner, the code belongs into a plugin, so the core application is flexible. wiki style : Traditionally, bug trackers only allow to add comments, but not to change anything. I believe the wiki approach, where everybody can edit everything, works better among developers. Discussion should take place on a mailing list, not within a bug report. For this special design decision it is opinionated software. The edit command will open an issue in your $EDITOR and let you edit everything in it.

: Traditionally, bug trackers only allow to add comments, but not to change anything. I believe the wiki approach, where everybody can edit everything, works better among developers. Discussion should take place on a mailing list, not within a bug report. For this special design decision it is opinionated software. The edit command will open an issue in your and let you edit everything in it. not distributed: While later can be adapted to a distributed workflow, a centralized backend plugin could be used as well.

Of course, there are some disadvantages, too. For example later is (currently) the wrong decision if end users, managers, translators or graphic designers are involved. There is no project management functionality built in. These things may be added via plugins at some point, but they will be of secondary importance to the lonesome-developer-with-a-console scenario.

Do you want to play with it? Try this:

$ git clone http://github.com/beza1e1/later.git Initialized empty Git repository in /home/beza1e1/test/later/.git/ remote: Counting objects: 82, done. remote: Compressing objects: 100% (78/78), done. remote: Total 82 (delta 36), reused 0 (delta 0) Unpacking objects: 100% (82/82), done. $ cd later $ ./later list Web frontend (confirmed, ee902fe7) What to do on no-command-given? (confirmed, e2df0108)

I am also using later in my home directory as a todo list. This is a sign of its usability and generality to me.

Try it! Write a plugin!

reddit discussion, hacker news discussion