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_setnfuit_set user/$u -name $name -email $addr
nfuit_properties nfuit_properties user/bob | while read key val; do
...; done
nfuit_lognfuit_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
