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_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
>

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

Reply via email to