On 8 February 2012 10:53, Ahmet Emre Çepoğlu <aecepoglu_AT_gmail.com> wrote:
> On Thu, Jan 26, 2012 at 2:40 AM, Paul Hoffman <nkuitse_AT_nkuitse.com> wrote:
>> 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.
>
> 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.
I find this idea quite interesting and would love to see this as a
prototype. Just sticking to a world-writable repo like our wiki for
the issue tracking, sounds fine.
I'm not sure about Pauls directory structure suggestion though, but it
looks ok for a start.
The web interface could be a simple rc extension for werc.
Btw. I would like you to use C and rc, not C and bash or something similar.
Cheers,
Anselm
Received on Wed Feb 08 2012 - 20:15:52 CET