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.
- 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. - 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!