Launchpad Bugs feature

[Jonathan Lange]

On 3/28/07, Ian Clatworthy <ian.clatworthy at internode.on.net> wrote:
> Martin Pool wrote:
> > 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.

Presumably, a plugin which scanned the commit message for the bug info
would make the --fixes option unnecessary. So,
    bzr commit -m "Fixes: lp:123"

would be equivalent to:
    bzr commit --fixes=lp:123

> >> 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.
>

I think that whatever nuances we provide in the protocol (i.e. the
revision properties) should be able to be specified using structured
command line arguments.

> 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.
>

We do plan on adding support for specs. That behaviour is not at all
specified yet. :)

I don't think there's anything wrong with plugins that do the commit
message scanning that you are suggesting. I think that coming up with
a single, generic commit scanner that would keep everybody happy would
be very difficult.

Initially, we should provide options that expose the API in a nice way.

> 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.
>

Yeah. Entering information twice is definitely not a good thing.

cheers,
jml