[MERGE] Initial support for marking bugs as fixed using bzr

[John Arbash Meinel]

Jonathan Lange wrote:
...

> I've added a simple news entry for the new option for commit. However,
> I couldn't find any bugs that this branch fixes. Got any in mind?
> 

more flexible options: support lists and python keywords
https://bugs.launchpad.net/bzr/+bug/105366

http://bazaar-vcs.org/Specs/RevisionBugMetadata
and
https://launchpad.net/products/bzr/+spec/revision-bug-metadata

I wasn't able to find any specific bugs for "closing bugs" :)


...

> I can't see that in my code. I see:
> 
> class cmd_commit(...):
>  def _get_bug_fix_properties(...):
>    properties = {}
>    ...
>    return properties
> 
>  def run(...):
>    properties = {}
>    properties.update(self._get_bug_fix_properties(...))
> 
> All the variables are local, not instance or class.

I probably just mis-read the diff then.

> 
>> bzr commit --fixes upstream:XXX
>>
>> seems nice.
>>
> 
> Trac isn't the fallback tracker. I just needed to have another simple
> non-Launchpad tracker in order to be able to write the sort of tests I
> wanted.
> 
> Regarding naming conflicts. The configuration is on the branch. As I
> understand Bazaar's config system, this means that you could define
>  trac_upstream_url = XXX
> on one branch and
>  bugzilla_upstream_url = YYY
> on another branch, and not worry about naming conflicts.
> 
> I'd be happy to switch to an explicitly configured tracker style, as
> long as 'lp:' resolves to Launchpad by default.
> 

...

> Fixed. 'errors' is still lazily imported -- is this correct?

It is "correct". At this point there is no need to lazily import it,
because it is fully imported somewhere. Though if we can track them all
down, we stand to save a moderate amount of time (it is one of the
slower non 3rd-party imports)

...

> 
> I usually use the second form also (afaict with these variable-width
> fonts). Changed to use that and assertIs.

You use variable width fonts while coding??? I guess as long as your
indentations end up correct.

> 
>>
>> 9) I'm a little concerned that the data is stored as "<bug_url>:<status>"
>> I don't remember any specific restrictions on revision properties, but I
>> think there are some things like they must be ascii, and shouldn't
>> contain spaces. Also, it seems like it should be:
>> bug: fixed <url>
>>
>> Otherwise if someone else decides to use a URL to indicate something
>> other than a bug, other processing code needs to say whether it
>> recognizes this exact url, etc.
>>
> 
> I see what you mean.
> 
> The only documentation I could find on revprop format is that the key
> could not contain spaces.
> 
> Perhaps "bugs: <bug_url> <status>, ..." would be better. That clearly
> groups all the bug info and maps from each bug to its new status.
>