launchpad development
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
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 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: 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.
