OT: Distributed bug tracking?

[Peter Arrenbrecht]

On Jan 3, 2008 4:23 PM, Marcin Kasperski <Marcin.Kasperski at softax.com.pl> wrote:
>
> ...
>
> In general, I kinda of like this tool. It is simple, similar in spirit
> with mercurial command line, light and better than ToDo.txt or sth
> similar. It does not seem suitable for larger projects with a lot of
> bugs or very long discussions, but for simple projects it is light
> and easy solution without bloat.
>
> And - indeed I can imagine such a Mercurial extension.

I don't see how a command line tool requiring people to download a bug
database is going to capture bug reports from a wider audience. It
seems to address mainly the tracking side for developers. If someone
did a web front end (like ikiwiki, but rather more polished, I guess),
then maybe.

But I'm also thinking that maybe such a thing could be used in
combination with an established online bug database, like Trac or
Jira. Make them maintain a bug repo in parallel with their own store,
and allow people to submit updates through pushes to that repo (which
must apply cleanly). Then, users and developers each get their own
tailored mode of interaction. And while we're at it, I think this
should be extended to the wiki side as well. Being able to work
offline on the wiki sounds good to me.

I realize this does not address keeping the bugs with the code so they
branch together. The latter certainly sounds nice from the developer's
point of view. But users (and to some extent developers too), will
want to see a global view of a bug's status across branches. This
might not be trivial given that comments and updates might be either
globally applicable or particular to a specific branch. Furthermore,
you may want more freedom to tag a bug as applicable to different
branches than through the flow of source changes. Consider a bug that
was opened in branch A. Then there were other, unrelated changes
committed in A. Now you realize the bug also applies to branch B.
Copying it to B requires cherrypicking.

I believe the most useful aspect of having the bug database within the
source repo is that the closing of bugs is automatically propagated
along with the fixes themselves. But this can be achieved through some
sort of convention like "fixes issue #xy" in commit messages and
subsequently parsing them in a post-commit hook in the central repo.

So in all, I currently think having the bugs in the source repo is not
the way to go.

Discussion welcome.

-peter