OT: Distributed bug tracking?

[Neal Becker]

Matt Nordhoff wrote:

> Matt Nordhoff wrote:
>> Paul Sargent wrote:
>>> Apologies for the off topic post, but it might swing around to being
>>> sort-of on topic.
>>>
>>> I've never found a bug tracker I liked, but that maybe because I don't
>>> know about the options. The big thing for me is that with all of the
>>> decentralised advantages we have now, the other major tool for doing
>>> collaborative development work is normally accessed through a web
>>> site. Often slow and in an entirely different environment to where I
>>> do all my other development work (CLIs and text editors), it becomes
>>> totally inaccessible when on the road.
>>>
>>> It strikes me that if the bug information was part of the source tree
>>> (with a web interface somewhere so that users / managers can still
>>> access it) then the information would be exactly where the developer
>>> needed it. It would also be easy to see which change sets resolved
>>> particular bugs because the change-set would include the change to the
>>> bug report.
>>>
>>> It seems like a simple directory will one file per bug report would be
>>> 80% of the way there. You'd then need some scripts to handle them in a
>>> controlled way.
>>>
>>> Does anybody know of a system like this out there?
>>> If not, would it make sense to implement this as a mercurial
>>> extension, with an extension to hgweb too?
>>>
>>> e.g.:
>>>    hg bug open            # opens a new bug in text editor
>>>    hg bug append <bug-id> # opens text editor to allow more
>>> information to be added
>>>    hg bug resolve <state> # sets the bug state to closed, duplicate,
>>> etc.
>>>    hg bug report <option> # report all bugs that match some predicate
>>>
>>> I think you might need some special merge logic, so that two people
>>> appending or resolving a bug clash in reasonable ways.
>>>
>>> Any interest? Any thoughts?
>> 
>> There's Bugs Everywhere (which works with bzr and Arch).
>> 
>> <http://www.panoramicfeedback.com/opensource/index.html>
>> 
>> I've never used it, so I don't know exactly how it works, but it seems
>> you use a "be" command, similar to your "hg bugs" example.
>> 
>> You can see the .be directory it uses in this project's code browser:
>> 
>> <http://codebrowse.launchpad.net/~aaron-bentley/bzrtools/bzrtools.dev/files>
>> 
>> If you like it, perhaps hg support could be added.
> 
> Uhh, I was looking at the be code to see how easy it would be to add hg
> support, and it seems it already has it.
> --

This sounds _very_ interesting.  Has anyone used be with hg?  What is it's status?