Bug Linking Part 1
The Launchpad team is planning a new feature that will allow you to link bugs to each other and describe their relationship. The general idea is that you can say one bug depends of the fix of another.
We’ll be asking you to help us decide the scope of this feature, so look out for invitations to user research sessions over the coming weeks if you’d like to get involved.
Key Issues
There are issues about the kinds of relationship that should be supported and the types of workflows to use them. Before I describe the workflows and relationships that we have discussed, I think I should first write about the existing bug linking features and hacks.
Affects Project or Package
Launchpad has always recognised that a bug can affect many projects and packages. Launchpad defines a bug as an issue that has a conversation. The information in the conversation is commonly public, but it might be private because it contains security, proprietary or personal information. An issue can affect one or more projects and packages, and each will track its own progress to close the bug.
A bug in a package often originates in the upstream project’s code. I assume that when I see a project and a package listed in the same bug that there is an upstream relationship, but that is not always the case. So some bugs affect multiple packages and projects? How do I interpret this? Maybe one project is a library used by other projects. Maybe the projects and packages cargo-cult broken code that require independent fixes. Maybe the code from one project is included in the source tree of other projects. When I look at the table of affected projects and packages on a bug, I have to guess how they relate. I don’t know if fixes happen in a sequence, or at the same time as each other. Is one project fixed automatically by a fix in another project?
Contributors from all the affected projects contribute to the conversation. The conversation can be hard to read when several projects are discussing their own solution. It is common for everyone from one project to unsubscribe from a bug when the project marks the bug as fixed. This is a case were users are still getting bug mail about an issue that is fixed for them. Maybe there’s more than one issue if there’s more than one conversation happening?
Duplicate
Users commonly report bugs that are duplicates of other bugs. Marking a bug a duplicate of another means that the conversation and progress about an issue is happening somewhere else.
It is common for duplicate bugs to affect different projects from the master bug. Was the duplicate wrong, or maybe Launchpad did not add the duplicate’s affected projects to the master bug’s affected projects?
I can mark your bug to be a duplicate of a bug that you can’t see (because it is private). This is very bad. If I do this, you cannot participate in the conversation to fix the bug, and you don’t know when the bug will be fixed. It is common practice to make the first reported occurrence of a bug the master of all the duplicates, but if the first occurrence has personal information in it, it probably cannot ever be public. Thoughtful users create public versions of bugs and make them the masters of the duplicates so that everyone can participate and be informed.
Links in Comments
Launchpad automatically links text that appears to be a bug number. A user can add a comment about another bug and any user can follow the link to see the bug.
There are many kinds of relationships described in comments which contain linked bugs: “B might be a duplicate of C”, “D must be fixed before E”, “F overlaps with G”, “H invalidates J”, “K is the same area of code as L”, “M is the master issue of N”. I cannot see the status of the linked bugs without opening the bug. Maybe the bug was marked invalid or fixed? Bug comments cannot be edited, so the links in the comments might be historic cruft.
Bug Tags
Bug tags allow projects to classify the themes described and implied in a bug. Projects can use many tags to state how a bug relates to a problem domain, a component, a subsystem, a feature, or an estimate of complexity. Launchpad does not impose an order upon bug tags.
Some projects repurpose/subvert bug tags to describe a relationship between two or more bugs. The tag might describe a relationship and master bug number, such as “dependent-on-123456” and a handful of bugs will use it. Multiple tags might be used on one bug to describe all the directions of the relationships. A search for the tag will show the related bugs and you can see their status, importances, and assignee. The tag becomes obsolete when all all its bugs are closed. There might be more obsolete bug tags then operational ones. Bug numbers embedded in the tags are not updated if one bug becomes the duplicate of another.
Bug Watches
Bug watches sync the status and comments of a bug in a remote bug tracker to Launchpad. Projects can state that the root cause of a problem is in another project, and that project uses another bug tracker. The bug watch is presented in the bug affects table as a separate row so that users can see the remote information with the Launchpad information.
When the bug watch reports the bug is fixed, the other projects can then prepare their fixes based on the watched project’s changes. Since the information is shown in the bug affects table, it has all the same relationship problems previously described. I do not know if I need to get the latest release from the watch project, or create patch, or do nothing. Launchpad interleaves the comments from the remote bug tracker with the Launchpad bug comments, which means there is more than one conversation happening. The UI does distinguish between the comments, but it is not always clear that there are two conversations in the UI and in email.
Next
Workflows that that use related bugs.
