Re: [dev] interested in issue tracker dev

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Wed, 8 Feb 2012 20:15:52 +0100

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

This archive was generated by hypermail 2.3.0 : Wed Feb 08 2012 - 20:24:05 CET