Re: [dev] interested in issue tracker dev

From: Paul Hoffman <>
Date: Wed, 25 Jan 2012 19:40:45 -0500

On Fri, Jan 13, 2012 at 03:27:26PM +0100, Paul Onyschuk wrote:
> On Thu, 12 Jan 2012 19:34:09 +0200
> aecepoglu_AT_ wrote:
> >
> > I might be interested in trying to help write one such suckless issue
> > tracker as requested on the webpage.
> >
> > I just want to ask;
> > What set of features are a must for you?
> >
> After reading some discussion I have some ideas. For small projects
> keeping TODO file in repository can work quite well. What about
> extending this idea?
> Use one of the mbox mail formats to store data:
> - mbox file per issue
> - treat first message in mbox as meta: modify and store common
> informations (priority, short description, category of issue and so on)
> there


> - store everything under version control system: closed/resolved issues
> can be moved to different branch (smaller checkout)


> This way data can be accessed very easily, some usage ideas:
> - searching for existing issues simple as checking out repository and
> "greping" files


> - nice time-line provided by version control system (history of
> commits): when issue was updated, closed, new response was send

Double yay.

> - advanced usage e.g. search for issues with specific priority, "cat"
> them into one file and open with your email client


> I think that would make some people happy.

Sounds like some good ideas to me.

> Use mailing list as main interface, web interface could just send
> messages to list. Every message would be automatically prefixed with
> issue ID, ID would be also used as name for mbox file. Version control
> system would provide some security against corruption (just rollback
> to previous working checkout).

I'm not crazy about shoehorning issue tracking into e-mail like this,
it's more complicated than it needs to be. Concentrate on simple, basic
storage and functions and let someone else who cares about a web
interface write one.

> Anyway those are just random ideas, not sure if that is the way to go.

That's good for starters. Here's a simple issue tracker repository
using directories, key-value text files, and symlinks:

                yolanda -> ../../../user/yolanda
            properties [status, description, whatever]
            history [log of activity, append-only]
            mail/ [maildir, mh mailbox, whatever]
                hjk987 -> ../../../attachment/hjk987
                abc123 -> ../../../ticket/abc123
            properties [name, e-mail address, etc.]
   [the file itself]

Simple, extensible (group/*, project/*, ticket/*/+watchers,
ticket/*/+parent, whatever), and if for some reason you don't want
symlinks you can manage the relationships between things some other way
(hard links, plain text files, whatever).

Call it nfuit (non-fucked up issue tracker) and write some shell
functions for convenience:

nfuit_create_repository nfuit_create_repository /path/to/another/repo
nfuit_create nfuit_create user/bob -name Bob -email
nfuit_set nfuit_set user/$u -name $name -email $addr
nfuit_properties nfuit_properties user/bob | while read key val; do ...; done
nfuit_log nfuit_log $(nfuit_now) ticket/123 created -by bob -status open
nfuit_exists if !nfuit_exists ticket/999; then ...; fi
nfuit_link nfuit_link user/bob +tickets ticket/666
nfuit_unlink # obvious
nfuit_links for t in $(nfuit_links user/yolanda +tickets); do ...; done
nfuit_is_linked if nfuit_is_linked user/$u +tickets ticket/123; then ...; fi
nfuit_lock nfuit_lock user/bob/properties
nfuit_unlock nfuit_unlock user/bob/properties

I've done most of this (in zsh). Then build the rest on top of this and
utils like grep, find, munpack, etc.


Paul Hoffman <>
Received on Thu Jan 26 2012 - 01:40:45 CET

This archive was generated by hypermail 2.3.0 : Thu Jan 26 2012 - 01:48:03 CET