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
Ick.
> - store everything under version control system: closed/resolved issues
> can be moved to different branch (smaller checkout)
Interesting.
> This way data can be accessed very easily, some usage ideas:
>
> - searching for existing issues simple as checking out repository and
> "greping" files
Yay.
> - 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
Excellent.
> 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:
/path/to/repo/
ticket/
abc123/
+owner/
yolanda -> ../../../user/yolanda
properties [status, description, whatever]
history [log of activity, append-only]
mail/ [maildir, mh mailbox, whatever]
+attachments/
hjk987 -> ../../../attachment/hjk987
user/
yolanda/
+tickets/
abc123 -> ../../../ticket/abc123
properties [name, e-mail address, etc.]
attachment/
hjk987/
properties
contents.foo [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 bob_AT_example.net
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.
--
Paul Hoffman <nkuitse_AT_nkuitse.com>
Received on Thu Jan 26 2012 - 01:40:45 CET