Re: [dev] interested in issue tracker dev

From: (wrong string) ÄŸlu <aecepoglu_AT_gmail.com>
Date: Wed, 8 Feb 2012 11:53:10 +0200

On Thu, Jan 26, 2012 at 2:40 AM, Paul Hoffman <nkuitse_AT_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
> 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.
>
> 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
Received on Wed Feb 08 2012 - 10:53:10 CET

This archive was generated by hypermail 2.3.0 : Wed Feb 08 2012 - 11:00:07 CET