Launchpad Entry: https://launchpad.net/products/bzr/+spec/revision-bug-metadata
Created: 2006-03-20 by MartinPool
Contributors: RobertCollins
This is a duplicate with https://launchpad.canonical.com/AutomaticBugBranchLinks
Summary
Many changes to source code relate to fixing bugs (including enhancement bugs). It is common practice to mention the bug number in the commit message. If the both the revision and the bug are known to Launchpad it can infer and display the connection.
Issues to be resolved:
- Making the link requires that the bug number be recognizable to Launchpad.
- How are bugs to be identified?
- How is that identification to be encoded in the commit? (As a pattern matched in freeform text, or as a special header?)
- Should we draw conclusions about bugs being automatically closed?
This is related to https://wiki.launchpad.canonical.com/BugBranchLinks which asks that it be possible to associate a branch, rather than a revision on a branch, with a bug.
Overview
This spec touches several areas. Here is an overview of the major topics:
- data model for bug-branch relationships in launchpad
- bug
- branch
- revision (optional)
- status (in progress/fix committed/abandoned/other)
- comment
- displaying bug-branch relationships
- taking actions on revisions
- bug tasks can be changed when a commit moves into the relevant branch
- make sure we know which branch is relevant
- should be in bug history (aka action log)
- should cause email to be sent, with a link
- link to branch registration
- user and interprocess interfaces to create this data
- links to bugs vs to bug branches
- user interface for marking bugs: explicit field vs recognizing from text in comments
- interesting but out-of-scope issues
- private branches/products/bugs
- security-related bugs
- projects in other version-control or bug-tracking systems imported into Launchpad
- bugs closed in package releases
Rationale
Revisions that relate to a bug can be linked from the bug view page.
Commits could potentially automatically close bugs, as is done in Debian and some other systems.
Further Details
Bugs vs bug tasks
Malone tracks "bug tasks", which represent the need to fix a bug in a particular location. Typically there is just one task: to fix the bug in the upstream source. However, it is common to also need to fix the bug in Ubuntu, or in Ubuntu Breezy. Fixing the bug upstream doesn't mean it's fixed in the distributions.
Tasks don't have their own numbers, but can be uniquely identified by the combination of the enclosing object (e.g. "/products/bzr") and the bug number. This may be too long for comfortable use in commit messages.
Other bug trackers
bzr uses launchpad "native" bug tracking -- bugs are created in Malone and not imported/linked from other systems. When we say "bug 3049", this always means http://launchpad.net/bugs/3049.
This is not true for other projects.
Some other projects may be unlucky enough to span multiple bug trackers, e.g. the project's own bug tracker, debian's bug tracker, and possibly a private bug tracker inside hp.
The solution that goes into bzr shouldn't be usable only with launchpad.
When a developer writes a commit message they likely have a bug tracker in mind and we don't want to force them to give e.g. a full bug url when an integer would seem to be sufficient.
Debian changelogs
Put in changelog that you've fixed a bug, and do a large amount of work before doing an upload that fixes the bug. So the bug is closed at the level of a very large commit -- essentially like a merge into mainline. No smaller work before the final merge takes place is considered.
This means it's OK for someone to change their mind about whether a particular commit fixes the bug or not. The very fine grained commits typically done on bzr working branches might cause too many bugs to be closed incorrectly.
Suggests that possibly only mainline revisions on the main branch (or pqm submissions) should be able to close bugs?
Possible relations of a revision to a bug
The simplest case demonstrated by much existing practice is "this revision fixes this bug". However, many others have been seen to occur:
- the bug is reproducible in this revision
- this revision partially fixes this bug
- this revision adds a test case for this bug (and that case may be currently disabled, or expected-failing, or skipped.)
- this revision adds a workaround or note about the bug to the documentation
This list is not a fully or fully-factored ontology of relations, but I think we can draw some conclusions:
- "$revision fixes $bug" is common but not the only case
- "$revision relates to $bug" may be a useful catch-all, covering nuances that can't be encoded in the database
- The human-readable message gives important context
"This time for sure!"
At the time revision r200 is made, the developer thinks it fixes bug b123. It's reasonable for launchpad to say that, to the best of its knowledge, b123 is fixed by r200.
After the revision is pushed, they discover that it wasn't actually fixed, and they make a new revision r201 which "really" fixes it, and push that.
We can draw a few consequences:
- After a bug is automatically closed, it should be possible for a user to reopen the bug, just as if it was closed through the web or email interface.
- After it is reopened, it should be possible for a later commit to close the bug.
Question: After r201 is seen, perhaps Launchpad should not consider that merging r200 into any other branch constitutes a fix for that branch?
Question: Should it be possible to reopen a bug through a commit message? There is no precedent for such a feature as far as I know. Often the bug is reopened by someone other than the developer of the attempted fix.
"Missed again!"
It's moderately common for commit messages to actually refer to the wrong bug, either because of a typo, or because the user misremembered the number or the exact point of the bug. This can make the revision refer to either the wrong bug, or to a bug which does not (yet) exist.
In bug trackers used for several projects (including Malone) the bug number may be that of a totally unrelated project.
If we automatically close bugs when a revision propagates into the branch corresponding to the bug task, then
- revisions mentioning bugs for the wrong project will have no effect
- revisions mentioning as-yet-unused bug numbers have no effect
- revisions mentioning already-closed bug numbers have no effect
- Revisions mentioning a bug number that is incorrect but otherwise plausible will cause the bug to be closed. This will generally send email to subscribers to the bug. They can notice the problem and reopen the bug.
We could optionally send an email note to the author when these situations are detected.
Bug nicknames
Malone allows users to attach short id-like nicknames to bugs, to save them from remembering arbitrary integer ids. These could be used in revision metadata, which might reduce the chance of entering the wrong bug id.
Question: can bug nicknames be deleted/changed/reused? If so we may need to "freeze" the nickname to a bug id at the moment the revision is seen.
Duplicated bugs
If a revision is committed which fixes a bug with duplicates, it should probably be considered to fix all of the bugs.
Linked bug trackers
Malone supports linking to bugs in other bug trackers (e.g. bugzilla). These systems use their own bug numbering sequences.
Imported revisions
Some projects might use Malone but not be developed in bzr. If their upstream source branches are imported into bzr we could support links to bugs at that point.
Imported revisions and bug trackers
Some p
A related case is a project that changes their bug tracker, e.g. from running their own Bugzilla installation to using Malone hosted on launchpad.net. In this case "bug 1" will mean something different to what it used to mean.
We should be O for
Failure cases and difficult cases
- A project changes bug tracker, so that "bug 1" in their context may mean different things depending on when it was said. (This is obviously something people would prefer to avoid but it does happen.)
Use Cases
Implementation
Implementation plan
We propose two main phases for implementation:
- Show bug-revision relationships, without automatically closing bugs.
- Automatically close bug tasks when revisions are merged into particular branches.
UI Changes
Code Changes
Schema Changes
Data Migration
Discussion
Unresolved Issues