= Revision-Bug Links =

Provide a link from a revision, not a branch, to a bug.  This is not really a feature, but is feature-sized because it changes a very old data-model decision.

'''Contact:''' AaronBentley <<BR>>
'''On Launchpad:''' ''Link to a blueprint, milestone or (best) a bug tag search across launchpad-project''

As a contributor to a launchpad-hosted project, I want to create links from revisions to the bugs they fix so that I can track them with greater accuracy.

As a contributor to a launchpad-hosted project, I want to be able to reuse branches and have bug info be reflected accurately.  (e.g. a merge proposal [[https://bugs.launchpad.net/launchpad/+bug/556990|should not show already-landed fixes]])

As an advanced user of a launchpad-hosted project, I want to see which bugs are unsolved in a given branch or series.

As an author of a script like the qa-tagger script, I want bugfixes to be connected revisions, so that my script will not be confused when people reuse branches.

Another LEP which involves QA and storing data about revisions is [[LEP/DeploymentQA]].  It may be convenient to implement both at the same time, but neither demands the other.

''Link this from [[LEP]]''

== Rationale ==

We are doing this now because our data model is limiting the accuracy of the qa-tagger script, making RFWTAD and monthly deployments harder than necessary.

Benefits to our users:
 * it becomes easier to determine which bugs are present it a given branch or series
 * the model maps more closely to bzr's model, which has always linked revisions to bugfixes.
 * our development process becomes more efficient, giving us more time for other work

Affected users:
 * Advanced users of launchpad-hosted projects
 * Contributors to launchpad-hosted projects
 * QA engineers of launchpad-hosted projects
 * Release managers of launchpad-hosted projects
 * People requesting nodowntime deployments of Launchpad

== Stakeholders ==

 * Advanced users of launchpad-hosted projects
 * Contributors to launchpad-hosted projects
 * QA engineers of launchpad-hosted projects
 * Release managers of launchpad-hosted projects
 * People requesting nodowntime deployments of Launchpad

== Constraints and Requirements ==

=== Must ===

* Provide precise information about which revision fixes a bug.
* Allow bug links to be revised (e.g. 
* Support CRUD over the web UI and API
* Be integrated into the branch scanner

=== Nice to have ===

Extra statuses, such as:
 * "Bad fix": the revision was thought to fix the bug, but actually did not
 * "Bug introduced": the revision introduces the bug rather than fixing it, allowing precise determination of which 
 * "Fix begins": the first revision in a series of revisions intended to fix the bug, making it possible to see a diff of the changes.


=== Must not ===

Use the deprecated BranchRevision table.

=== Out of scope ===

== Subfeatures ==

None

== Workflows ==

When a user selects the "fix committed" status, they are prompted for a branch and revno.  The revno defaults to the branch tip.
(This is stored as a revision-id, however.)

When a user commits with --fixes, and pushes, Launchpad's branch scanner associates the revision, not the branch, with the bug.

When a user views a merge proposal, only the bugs fixed by revisions introduced by the merge proposal are shown.

When a person is doing QA and they determine that a bugfix did not solve the bug, they mark the revision link as "bad-fix", rather than tagging the bug.

== Success ==

'''Bugs are at:''' [[https://launchpad.net/launchpad-project/+bugs?field.tag=$LEPNAME|Bugs for this LEP]] ''link to a search for a bug tag or milestone. Use launchpad-project rather than a sub-project.''

=== How will we know when we are done? ===
There are links from revisions to bugs

=== How will we measure how well we have done? ===
Hard to say.

== Thoughts? ==

Data migration will be a huge problem, because we are moving from a less-precise model to a more-precise one.  This means that migrating old bug-branch links may not link to the correct revision (e.g. where branches have been reused).  We should consider retaining bug-branch links, or having a transition period where both are supported.