Extract bug fixing information from commit messages

[Václav Šmilauer]

Bug 318439 describes automatically changing bug status based on --fixes information in the revision.

It would be nice if we also extracted this information from the commit message.

Original description:
I had recently external SVN repository imported and it is synchronized with bzr at LP regularly (https://launchpad.net/yade/trunk). Since we use LP's bugtracker for bugs, I was hoping that https://wiki.ubuntu.com/ClosingBugsFromChangelog would work as it does for packages: saying "LP: #123456" in the changelog would make Launchpad Janitor close bug #123456. But it is not the case (tried with commit http://bazaar.launchpad.net/~vcs-imports/yade/trunk/revision/156).

This is the way it works for package changelogs. It is a very convenient feature; perhaps the bug should be marked as "fix commited" if LP: #.... is in commit log and "fix released" if it appears in package changelog.

[Jonathan Lange (jml)]

There are two distinct problems to solve here.

 1. Automatically closing bugs based on information in branches.
 2. Extracting that information from branches.

We already do 2. to some extent: we'll create a bug-branch link if you close a bug using 'bzr commit --fixes lp:1235'. This stores some data in the revision which Launchpad then extracts. It would be relatively easy to add a Bazaar plugin that parses the commit message and stores similar revision data. Analyzing a changelog on commit might be a little trickier.

Automatically closing bugs has been discussed before (although I don't have a link handy). It's something we've been keen to do for a while, but something that we also want to get right.

[Martin Pool (mbp)]

On Thu, Jun 26, 2008 at 10:20 AM, Jonathan Lange <email address hidden> wrote:
> Automatically closing bugs has been discussed before (although I don't
> have a link handy). It's something we've been keen to do for a while,
> but something that we also want to get right.

It partly relates to the various statuses (in progress, fix committed,
fix released) not being used completely consistently across projects,
arguably because they are not really clearly defined in Launchpad.

However, I think a reasonable place to start would be: fix committed
when such a revision is seen anywhere, and fix released when it goes
into a series branch. At least it would be worth trying this to get
feedback.

--
Martin <http://launchpad.net/~mbp/>

[Jonathan Lange (jml)]

Except that the currently encouraged use of statuses is for 'fix committed' to mean 'on trunk' and 'fix released' to mean "it's been released".

[Andrew Bennetts (spiv)]

Well, for many projects we know which branch is the "development focus". So if such a revision is seen on that branch, then "fix committed" seems like a completely safe thing to infer.

[Matthew Paul Thomas (mpt)]

For "Fix Committed" vs. "Fix Released" generally, see bug 163694. For the purposes of this bug, I think changing reports to "Fix Committed" when seen in the project's mainline would be a good start.

[Emmet Hikory (persia)]

Also see bug #41702 and bug #163696. A solution for these may be a means by which a given set of bugs in the "Fix Committed" state may be pushed to "Fix Released" when bundling a release.

[Colin Watson (cjwatson)]

At the moment we don't have a proper notion (except informally) of what the "development focus" is for a source package in a distribution. When we have source package branches (which the Launchpad Code team is working on), then this will be a meaningful concept.

[Colin Watson (cjwatson)]

Following bug 261445, commits of changes that fix Ubuntu bugs will generally use 'bzr commit --fixes', assuming that the committer is using debcommit.