Bug links are a way of indicating that two bugs are related.

Using the affect project or distro link will disclose private information in bug comments, commentators, and subscribers to the other project if the project is added as a bug task to the bug. The link could copy the public portion of the bug and permit the user to redact the description to create a new bug. The two bugs are linked and users with permissions to see both projects/bugs may see that they are linked. The links could explain their relationship, such as IS, LIKE, or DEPENDS.

Rationale

We are creating private projects. There is a large risk that confidential information will be disclosed if projects share bugs. Instead of supporting multiple bug tasks per bug (where each bug target is a Canonical partner), Launchpad could link bugs together so that Canonical employees can see that the two bugs are linked, but the partners cannot.

It is common practice is to report another bug on the other project instead of adding another task. The situation will continue to exist after Canonical is using private projects, but the inconvenience can be solved. The form that asks the user to select the affected target can also allow the user to edit the title and comment. The linked bugs may share status like a bug watch so that when the bug defined to be the origin is fixed, the copies are updated.

Stakeholders

• OEM (Joey Stanford, Steve Magoun, Cody A.W. Somerville)
• Hardware enablement (Chris Van Hoof, Hugh Blemings)
• Ubuntu (Bryce Harrington)

User stories

As a driver of a private project
I want clone and link a bug that affects another project
so that confidential info is not disclosed to the other project

As a contributor to a private project
I want clone and link a bug that affects another project
so that confidential info is not disclosed to the other project

As a contributor to multiple projects
I want to be able to clone a bug from one project to another project
so that I can have separate conversations about the bug, each with their own disclosure level

Constraints and Requirements

Must

1. When reporting that a bug affects another target with a potentially different privacy situation, a user should not have to consider whether or not to clone the bug, but rather Launchpad must do it automatically if required.

2. The form must prompt the user to edit the title and description
   The user must ensure the information does not disclose confidential information. Ideally, if the title and description are fine, then choosing the affected project is all that the user needs to do.

3. Users with access to both linked bugs can see that they are linked.
   While users can clone bugs by re-reporting a bug, it is not possible to link the bugs. So in the many cases where this was done, engineers cannot easily track to cloned bugs.

Nice to have

1. Linked bugs get status updates like bug watches.
   When the origin-bug (the zero-vector in an infestation) is fixed, the clones indicate that a fix is available, or is fixed automatically.

2. Bug links can describe the relationship of the link.
   It is common for the fix for one bug to depend on another, it would be nice to express that. Some bugs are made invalid if another bug is fixed.

Must not

1. Do not require user to learn another way to say the bug affects another

   project.
   The existing workflow must recognise the situation, and prompt for the extra information to clone the bug.

Subfeatures

None.

Workflows

1. Affects project|distro clones private bugs instead of add a task.
   When a bug is private (explicitly private or because the project it belongs to is private), the form allows the user to edit the title and description and clones the bug and links it to the other bug.

Success

How will we know when we are done?

1. A user can clone a bug faster than he can recreate it.
2. A bug without confidential information in the title and description can be created in the same number of presses as adding another bug task.
3. A user can see that the linked bugs and knows the origin-bug.

How will we measure how well we have done?

1. Maybe measuring the time saves tracking the unlinked re-reported bugs.

Thoughts?

Curtis:

• Bug links relate to bug tags. Bug tags define a "like" relationship and that usually needs to be qualified. Bug tags doe not support dependency, nor do they point the direction

jml

• Does "origin" really matter?
• Have you seen mpt's thoughts on bug linking / dependencies?
• How visible are the bug links themselves? Can I see that there are linked bugs? If not, where do the events that change my bug come from?