OT: Distributed bug tracking?

[Peter Arrenbrecht]

Hi Dmitriy

> It sounds like a good idea to consider storing comments in separate files.

Using a hash over the text as the name to avoid collisions?

> The next thing I'll implement (when I have time again is ability to
> attach files to comments and the issues themselves).

>From the previous discussion, I gathered people would be using this to
basically replace internal TODO lists. I don't think attachments (and
comments, for that matter) will be very important then. After all, do
you guys really envision a discussion taking place via comment
commits? Or would they get added after the fact, copy/pasting from IRC
or email? That, then, would require a ui that plays well with
copy/paste.

I guess I'm still failing to see how this is going to be valuable in
practice. Can anyone enlighten me beyond the basic TODO list case?

-peter


On Jan 4, 2008 3:27 PM, Dmitriy Morozov <hg at foxcub.org> wrote:
> Hi, Paul (and the rest of the Mercurial mailing list),
>
> Just before the New Year I started writing pretty much exactly what
> you described in your email (I've been wanting a system like this for
> a while, and finally realized that implementing it as an extension is
> the easiest way to go). It's very preliminary at the moment, but it
> does all of the things you described in the original email. The main
> things missing are adding file attachments, integration with commit,
> and integration with hgweb (I don't know how feasible the last one
> is).
>
> What you called hg bug open, I called hg iadd; hg bug append <bug-id>,
> I called hg iadd <bug-id>, or hg iadd <bug-id> <comment-id> (it allows
> for threading of messages); hg bug resolve <state> is hg iupdate
> <bug-id> -p property=value (e.g., -p state=fixed); hg bug report
> <option>, I called hg ilist -p property=value or -f filtername (to
> list those issues that match some requirements given explicitly on
> command line, or in a pre-defined filter); plus there is hg ishow
> <bug-id> [comment-id] to actually view the issues (or comments to
> them).
>
> The issues are stored in files in hgroot/.issues directory. Each issue
> is its own file in mbox format (so in particular you can open it in,
> say, mutt and still read all the contents). The properties (e.g.,
> State) are simply stored as message headers. Merging is trivial,
> although requires manual involvement if there are conflicts. It sounds
> like a good idea to consider storing comments in separate files (I
> guess storing issues in Maildir format instead of mbox format) which
> should get rid of the manual merging if there are updates in different
> branches.
>
> Anyway, I called the extension Artemis, you can clone a copy from
> http://www.cs.duke.edu/~morozov/repos/Artemis/
>
> The next thing I'll implement (when I have time again is ability to
> attach files to comments and the issues themselves).
>
> Let me know what you think.
>
> Best,
> Dmitriy
>
> 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?
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>