On Thu, 22 Apr 2010 14:37:26 -0300, David Bremner <bremner@unb.ca> wrote: > It was thinking along these lines that got me to make the following list > > http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/ I'm not sure what it is you think of as a "git-based issue tracker". Or rather, I'm not sure if we have the same ideas about what would make a git-based issue tracker interesting. > If people think the general concept of a distributed bug tracker is > worthwhile, I'm willing to investigate a more. Feel free to cc For me, having an issue tracker be git-based might help with what really matters, but wouldn't necessarily. One realization is that since we have distributed code, we necessarily have distributed bug state. (The bugs that exist in my repository are distinct from the bugs that exist in your repository.) So if bug state can follow the way code moves, then that is interesting. For example, if dme commits a fix and marks "issue #217 closed" with that fix, then I'd like my repository of bugs to also know to close that issue when I later merge his fix. To me, that's really a user-interface issue, more than a storage issue. I don't care if the issue tracker stores its state in a git database. But I do care that it be able to watch what we are already doing, (creating git commits and sharing them), in order for us to easily track state. It seems to me that almost all issues of interest are already raised on this mailing list, and later followed up with a message from me, (along the lines of "thanks, this is pushed"). So I'd be happy with a system that relied on an email interface as well. What I don't want is something that would make me go push buttons in a web form in addition to the "git push" and sending of email that I'm already doing. My primary metric for adopting a new issue tracker is "how little extra work will I have to do to use this compared to what I'm already doing?". That's a lot more important to me than how the system stores its data. -Carl