bug tracking

[Mark Anderson]

On Thu, 29 Apr 2010 12:48:38 -0500, Servilio Afre Puentes <servilio at gmail.com> wrote:
> 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

Wouldn't it be good to have a timestamp associated with the application
of a tag, especially if you're going to manage a bug workflow with tags?

You'll be going cross geography, so UTC sounds nice.

But what happens if a bug goes from OPEN->CLOSED->REOPENED->CLOSED->...,
can you track that state with a simple tag cloud?

How would you handle conflicts for the bug tracker?  Suppose two people
close the bug in different ways, and one fix goes through several state
switches before being committed to a globally visible repository.

Does this really work with distributed development?

Although a permutation of that question might be:

What does a distributed bug tracker look like?

You will have multiple bug DB's in different states, so do we default to
having a tie-breaker "master" DB designated by the community?

Distributed bug tracking - I'm certain it means different things to
different people, perhaps we ought to specify what it means with a bit
more clarity before jumping off and developing it. 

Nah, too much central control, just develop what you want, we'll bend it
and the conversation about what it means until they fit. ;}

Enjoy,
-Mark