On 12 January 2012 19:06, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> One of the most important things of such a tracker is decent mail
> integration in my opinion (as most trackers that have evolved in the
> OSS space recently suck very much when it comes to mail integration).
>
> One aspect of this tracker could be to start with a proper mail
> archiving system and then writing the web stuff on top. This would
> allow proper querying. The mail archiving could be based on a
> repository storage (hg or git) instead of some poor database based
> system.
The reason I suggest to base the bug tracker "view" on a mail
archiving tool is simply because this problem hasn't been solved in an
acceptable way either (and we'd need a better system anyways).
I wouldn't go as far as asking for a web app, rather a proper static
mail archive generator that can be indexed by popular search engines
easily.
The logic aspect of the bug tracker should be controlled by mail
addresses only (I don't like the mail header approach, just make it
absolutely simple and work on mail addresses). One way I imagine this
could be:
New issue is reported to: bugs_AT_suckless.org (which is a read-only
mailing list otherwise). When the new issue is received the BTS will
prefix the subject to:
[id] <previous subject>
For example
[89] dwm crashes if I click on the status bar on any Friday the 13th
The BTS will also register the recipient:
bug-id_AT_suckless.org -> status is "NEW"
(in the above example bug-89_AT_suckless.org)
Afterwards all bug-related communication targets this email address. A
suckless developer with the permission to amend the bug status could
now send special commands to this address:
bug-id+work_AT_suckless.org (accepts and opens the bug, indicating work
in progress) -> status changes to "IN PROGRESS"
bug-id+invalid_AT_suckless.org (rejects the bug and closes it) -> status
changes to "CLOSED: INVALID"
bug-id+fixed_AT_suckless.org (closes the bug and marks it as fixed) ->
status changes to "CLOSED: FIXED"
Once a bug has been closed with "+invalid" or "+fixed" the BTS will
subsequent mails to bug-id_AT_suckless.org.
Comments or confirmations of a fix have to be send prior to "+invalid"
or "+fixed".
If someone is unhappy that a bug was closed, issue a new bug. Closing
a bug should be a final operation (in my experience this is one
problem with the existing BTS that allow re-opening closed bugs, but
re-opening closed bugs means your working style sucks)
That's how I imagine it.
Cheers,
Anselm
Received on Sun Jan 15 2012 - 08:06:55 CET