launchpad development|
Size: 3872
Comment:
|
← Revision 11 as of 2012-06-22 13:49:07 ⇥
Size: 4552
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 7: | Line 7: |
| 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 make use of Launchpad's revised privacy features. | 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. |
| Line 23: | Line 23: |
| For example: Project Wunderbar is private and represents a commercial development relationship between LovelyCorp and its client Geronimo Inc. | 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. |
| Line 25: | Line 25: |
| Geronimo Inc finds a bug in an Ubuntu package and would like LovelyCorp to fix that for them. In a non-security context, the existence of that bug should be public knowledge because Ubuntu is free software and an interested party likely exists around the package. LovelyCorp want to make the fix in public and push it straight to the Ubuntu package. However, they do not want to expose the existence of their commercial relationship withb Geronimo Inc. | 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. |
| Line 27: | Line 27: |
| If they had two bug tasks, one for the Ubuntu package and one for the private Project Wunderbar, they could: | 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. |
| Line 29: | Line 29: |
| * expose the existince of the private Project Wunderbar * expose the existince of the commercial relationship * risk exposing commercially sensitive information in the public bug's comments. |
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. |
| Line 33: | Line 35: |
| Right now, LovelyCorp could create a totally separate private bug in Project Wunderbar and put a manual link to the public bug in the private bug's comments. However, that means they lose the benefits of a shared bug report. | 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. |
| Line 37: | Line 39: |
| We are doing this now so that private projects are useful to Canonical's PES team. | We are doing this now so that private projects are useful to Canonical's PES team and also the GSS team. |
| Line 43: | Line 45: |
| * Steve Magoun * Cody Sommerville |
|
| Line 48: | Line 48: |
| * Jose Plans * Martin Staedtler |
== Personas == |
| Line 51: | Line 51: |
| * Kev: software engineer in PES's Infracstructure team. * Chris: enablement engineer in PES * Brian: project manager in PES * Esme: software engineer in Sustaining Engineering |
|
| Line 55: | Line 60: |
| === $STORY_NAME === | === Private bug dependent on public bug === |
| Line 57: | Line 62: |
| '''As a ''' $PERSON<<BR>> '''I want ''' $FEATURE<<BR>> '''so that ''' $BENEFIT<<BR>> |
'''As''' Kev<<BR>> '''I want''' to specify that a private bug report is dependent on one or more public bug reports<<BR>> '''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.<<BR>> |
| Line 61: | Line 66: |
| ''Have as many as you like. Group user stories together into meaningfully deliverable units. They'll be used as the driving elements of exploratory testing QA.'' | === Track sensitive info in private bug, fix in public bug === '''As''' Esme<<BR>> '''I want''' to link a private bug to a public bug, without exposing the private bug's existence or data<<BR>> '''so that''' I can have on place to view all activity pertaining to the issue but keep private the commercially sensitive information. |
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.
