On Thu, Jan 26, 2012 at 2:40 AM, Paul Hoffman nkui...@nkuitse.com wrote:
- 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
Well, this sounds functional enough, but... I feel that maybe I am
considering it to be simpler than it actually is. This is what I understand:
-Now, the issue tracker application manages the creation and modification
of a folder as you said.
-All the issue tracking data sits in this folder. This folder sits inside a
version-controlled folder (so, this folder replaces the TODO files we swap
around, if you place it together with the source code)
-Then all I have to do is write a simple bash or C program with a couple of
features (like the ones you listed).
- If control through email is requested, another app should be written that
extends an email handling system.
- If anyone wants a web interface, that too would be done with another
application.
Something this simple I feel would have been done already. What am I
missing?
If nothing, I could get started right away.
Cheers
