bug tracking

[Jesse Rosenthal]

Just a response to some of Mark's points, re. the very rough prototype I
mentioned in another email in this thread:

id:m1k4rkkchy.fsf at watt.gilman.jhu.edu

All of my answers are based on my current implementation, and don't
necessarily reflect the best possible way to address these problems.

On Thu, 29 Apr 2010 14:01:59 -0600, Mark Anderson <MarkR.Anderson at amd.com> wrote
> 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?

I sort of fake this by having timestamps come with pushing. Of course
then it doesn't reflect the time of the tagging, but the time of the
pushing. But if there were an internal db timestamp on the tag, that
might be even better.

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

Yeah, I should change it to that.

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

Depends if you push in intermediate states. It will be recorded as
prefaced with a + or - depending. See the link I give to a sample public
log in the announcement email. The file that you push to/pull from will
thus have a whole history for each tag in the namespace. Note that it
will be "reduced" before being applied to your current db, when you
pull.

> 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.

The tag would only be in your inbox in its latest state. (See above
about "reducing" before applying.) But you can see the history for any
msg-id.

> Does this really work with distributed development?

No idea. Worth a try.

Best,
Jesse