No subject

"ideal". But in a distributed world with lots of bug trackers, it isn't
really practical.

I also don't really want to have another mini-language for describing
bugs. It may be enough to have "<url> <status>, <url> <status>,...".

But what if we did something like use a bencoded dict. I don't
particularly like bencoding, but Martin used it for Tags, and so we
already have the code available.

Another possibility would be a Rio format, something like:

url: https://launchpad.net/bugs/100200
status: fixed
url: foo
status: fixing

...



> No worries. The main confusion was not always knowing which file had
> the code that you were commenting on. Thankfully grep and memory serve
> well.

Yeah. Reviewing through Bundle Buggy encourages short comments, rather
than in-depth reviews. So usually I do full reviews through Thunderbird.
But IIRC, your bundle was attached as binary (not inline text), so I
couldn't review it that.

I probably should have just downloaded your bundle and used Vim.

> 
> Thanks for the helpful review.
> 
> cheers,
> jml
> 

By the way:
http://bazaar-vcs.org/Specs/RevisionBugMetadata

brings up some good points about "oops, I didn't really fix the bug".
Because Revision properties are considered immutable, they aren't the
best way to implement something like this.

I'm willing to accept it for now, because I'd rather have something than
nothing.

Ultimately, I think having versioned meta-data might be an answer. It
can be used to solve a lot of different pieces (tags, changing commit
messages, bug status). It adds another layer of complexity, which is why
we haven't added it yet. (Especially when you start merging any of those
changes and dealing with potential conflicts).

John
=:->