On Fri, Jan 13, 2012 at 03:27:26PM +0100, Paul Onyschuk wrote: > On Thu, 12 Jan 2012 19:34:09 +0200 > aecepoglu@ 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 b...@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 <nkui...@nkuitse.com>