bug tracking

[Servilio Afre Puentes]

On 28 April 2010 16:34, David Bremner <bremner at unb.ca> wrote:
[...]
> Meanwhile Jesse Rosenthal and I started chatting about, and Jesse
> started implementing, some tools for grabbing remote collections of tags
> and merging them into their own namespace.  This may give us a
> notmuch-oriented way of managing the mailing list a bit better as a kind
> of bug tracker. I don't want to promise things on Jesse's behalf, but I
> personally am holding off on further bug tracker experiments until I see
> how this works out.

I have been playing in my head with the idea of using notmuch to track
bugs, thinking of ways it could be done. Using tags and searches this
should be fine, and even (if not right now, I am sure in the future we
will) easily see what bugs have patches/pull requests proposed[1].

While reading your message, David, I think I've found and idea might
enable this: enabling the dump command to accept a search term. With
this in place, our bug database can be composed of the mail archive +
a dump of the tags used for bug management.

There another wrinkle with this approach, but a solvable one I think:
the current implementation of the restore command will wipe all local
state for the related messages. This is really bad for people tracking
individually bugs/features in their local notmuch databases, e.g.:
using tags such as TODO, REVIEW, etc.

But with a way of non-destructively applying a set of tags to a
messages we could have a distributed issue/feature/etc tracking system
that is 100% notmuch-based and message driven (PR for the feature, we
have to think forward!).

IMHO this will allow for totally awesome workflows.

And we should name it "notmuch issues" or "notmuch bugs".

Servilio

[1] I like pull request because they are easier to manage: you don't
need to resend the patch series when you need to update your work.