• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

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 make use of Launchpad's revised privacy features.

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: Project Wunderbar is private and represents a commercial development relationship between LovelyCorp and its client Geronimo Inc.

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 they had two bug tasks, one for the Ubuntu package and one for the private Project Wunderbar, they could:

• 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.

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.

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.

Stakeholders

• Canonical's PES:
  • David Murphy
  • Steve Magoun
  • Cody Sommerville
• Curtis Hovey (Purple squad lead, working on Better Privacy)
• Canonical's Global Support Service
  • Ezio de Mauro
  • Jose Plans
  • Martin Staedtler

User stories

$STORY_NAME

As a $PERSON
I want $FEATURE
so that $BENEFIT

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.

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.