On Fri, 13 Jan 2012 17:22:12 -0600
Hank Donnay wrote:
>
> I like the idea of maildir-in-git, it makes something like
> automatically generating a website trivial with hooks.
>
Maildir is a bit overkill in my opinion, just look at naming convention
[1]. If you want to use "file per message" format, MH provides simpler
solution (name of file is just a ID number e.g. 1, 2, 15 and so on).
On Sat, 14 Jan 2012 02:25:03 +0100
hiro wrote:
>
> Editing the sentences and then deleting all useless entries or
> redundant letters keeps everything tidy. And from your text editor you
> can just save the edited content to TODO.
>
It could work nicely with MH mail format. Just delete redundant
message stored as file and push to repository. Edit content/header of
first message and you're done.
Creating shell/awk (or whatever you use) script for creating issue by
directly writing to repository shouldn't be much problem either.
Although folder naming of issues should be based on hashes created with
some salt in this case to avoid conflicts. Editing/modifying is smaller
problem I think - version control systems can handle pretty well
merging.
On Fri, 13 Jan 2012 15:48:43
+0100 markus schnalke wrote:
>
> Well, you might want to update these attributes in the first
> message, to have the latest state there, but in its header.
>
I don't see a point of storing meta-information in header of every
message. In my opinion headers of every message beside first one
should be stripped to minimum ("From", "To" and "Subject" etc).
Otherwise you'll get 20 or so lines for header just to accompany few
words long body e.g. "Check [xxxxxx] revision and let me know if that
fixed bug for you".
With mailing list-like interface those could be send, but storing that
is whole different case.
On Sat, 14 Jan 2012 09:25:14 +0200
aecepoglu_AT_ wrote:
>
> I am not very knowledgable when it comes to the use cases of a issue
> tracking tool. That's why I need to know what you guys want and do
> not want. Keep it going guys.
>
The problem is that it is easier to answer question "How issue tracker
should not look like" than other way around. Maybe there is a better
way to write suckless issue tracker than current proposals.
[1]
http://cr.yp.to/proto/maildir.html
Received on Sat Jan 14 2012 - 12:26:45 CET