Launchpad Bugs feature

[Ian Clatworthy]

Martin Pool wrote:
> On 3/28/07, Jonathan Lange <jml at mumak.net> wrote:
>> Hello,
>>
>> I'm at the Bzr mini-sprint in Sydney working on a feature to allow
>
> "Bazaar" :-)
>
> http://bazaar-vcs.org/Branding
>
>> To indicate that a revision fixes a bug:
>>     * bzr commit --fixes=62789
>
> That looks good.  You should be able to repeat the option.
>
> It's worth mentioning that people might like to scan for patterns in
> the freeform commit message mentioning a bug.  We're not excluding
> that, but taking the data in a structured form is simpler to do at
> first.
>
The only catch with this is that the information could/should get 
repeated, once in the --fixes option and a second time embedded in the 
commit message. I think the latter is still expected in many teams.
>> The bug number perhaps should be qualified to indicate that it refers
>> explicitly to a Launchpad bug, for example:
>>     * bzr commit --fixes=lp:62789
>>
>> (This lets us use the same option to fix Debian bugs and so forth).
>>
>> In future, we may want to provide the ability to set bug status before
>> the commit:
>>     * bzr bugfix BUG [STATUS]
>>       bzr commit
>>
>> And also perhaps to set the status to something other than 'fixed'
>> (e.g. 'in progress')
>>     * bzr commit --fixing=lp:62789
>>
>>
>> At the moment, I'm planning on including each bug as a revision
>> property which maps 'lp:<bug_id>' to '<status>', where status is
>> "fixed" (at least for the first iteration).
>
> It seems a little odd that this will proliferate options for every
> different status.  Maybe you could have
>
>  commit --bug 123:fixed --bug 324:fixing
>
> Not sure.
>

I agree that an option per activity is not the way to go. My preference 
is that the nuances of fixed vs fixing vs ... be embedded in the commit 
message. Because it will be anyway, particularly for those committing 
via IDEs.

Commits ought to be linkable with bugs/issues initially and specs, etc. 
later, yes? In that case, my suggestion is that the option name ought to 
highlight the action (linking/associating) and the target system(s). For 
example, a project that is still tracking bugs elsewhere (e.g. JIRA) but 
using Launchpad blueprints might instruct their developers to do 
something like this:

  bzr commit --link lp --link jira -m"Initial cut of my-lp-spec-name and 
fixes ABC-345"

The point is that the parsing of commit messages is likely to use smarts 
to extract bug-ids, spec-ids, etc based on the naming conventions of the 
linked tools. This approach also lets bzr developers use aliases to make 
the linking implicit for their environment.

As far as implementation goes, we certainly want access to (parsed or 
otherwise) metadata on a per system basis. Asking bzr for blueprint 
metadata on a commit ought to say "spec-name:comment", e.g. 
"my-lpspec-name:Initial cut of". The key point is that I don't want to 
enter that metadata twice.

My 2c,
Ian C.