launchpad development
Bug relationships 2012
Several types of relationship exist between bugs track by Launchpad, such as duplicates, bug watches and dependencies.
However, Launchpad's support for these relationships ranges from good, through poor, to non-existant.
People work around what issues there are but changes to how Launchpad handles private information mean that we now need to reconsider how best to track the different relationships between bugs. Specifically, we need to make whatever changes are necessary to enable Canonical's PES team to use private projects.
This project is not a chance to fix every problem affecting anything that resembles a bug relationship. However, this work will benefit almost everyone using the Launchpad bug tracker.
Contact: Matthew Revell
On Launchpad: bug-relationships tag, blueprint with work items to come soon
Rationale
Amongst much else, the Better Privacy project will give Launchpad:
- private projects
- a consistent and sane way to manage the disclosure of a project's private artefacts.
In a world where Launchpad projects can be truly private or particular bugs can have several types of privacy, Launchpad's unique "one bug, many contexts" approach becomes less appropriate.
For example: Canonical provides commercial support to Burble. Someone at Burble comes across a bug in an Ubuntu package and they want Canonical to fix it as part of their contract with us.
If it's not a security issue, the existence of that bug should be public knowledge because Ubuntu is developed in the open. Indeed, the bug may already have been reported publicly before Burble raised it with Canonical.
Canonical's Sustaining Engineering team will work on the fix for Burble. Burble expect to be able to track the progress of the fix and to discuss it with the Sustaining Engineering team. Sustaining Engineering have a private launchpad.net/burble project that they use to track bugs just like this one.
If they add a new Burble bug task on the public bug, that exposes several things, including:
- the existence of the commercial relationship between Canonical and Burble
- the fact that Burble are interested in that bug
- commercially sensitive information in the bug's comments.
If Sustaining Engineering create a separate private bug, they protect sensitive information but lose the agility that Launchpad's "one bug, many contexts" approach gives them. They can no longer see the detail of the public bug that they care about, instead they are locked into the coccoon of their private bug.
Private-public bug links allow us to keep private information private while making explicit the relationship between a private bug and its public counterpart.
We are doing this now so that private projects are useful to Canonical's PES team and also the GSS team.
Stakeholders
- Canonical's PES:
- David Murphy
- Curtis Hovey (Purple squad lead, working on Better Privacy)
- Canonical's Global Support Service
- Ezio de Mauro
Personas
- Kev: software engineer in PES's Infracstructure team.
- Chris: enablement engineer in PES
- Brian: project manager in PES
- Esme: software engineer in Sustaining Engineering
User stories
Private bug dependent on public bug
As Kev
I want to specify that a private bug report is dependent on one or more public bug reports
so that I can get on with other work until the public bug(s) has been fixed and I can use that work to fix the private bug.
Track sensitive info in private bug, fix in public bug
As Esme
I want to link a private bug to a public bug, without exposing the private bug's existence or data
so that I can have on place to view all activity pertaining to the issue but keep private the commercially sensitive information.
Constraints and Requirements
Must
What MUST the new behaviour provide?
Nice to have
Must not
What MUST it not do?
Out of scope
Subfeatures
Other LaunchpadEnhancementProposals that form a part of this one.
Success
How will we know when we are done?
How will we measure how well we have done?
Thoughts?
Put everything else here. Better out than in.
