launchpadblog

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. The goal is to make it clear where conversations to fix issues take place, who will do the work, and when the work can start.

I summarised the existing bug linking features and hacks previously. Now I want to explain the workflows and UI that Launchpad could support to create and explain relationships between bugs.

Managing bug relationships

Organisations and communities split issues into separate bugs when different people work at different times with different priorities to solve the bigger issue. Organisations and communities merge bugs when they want a single conversation to fix an issue that affects several projects at a single time. Explicit relationship between bugs (or the many projects listed on a single bug) would help projects organise work.

There are four general relationships that people try to describe when working to fix an issue. These relationship are either explicit, or implied when a bug affects multiple projects, or many bugs affect a single project. The relationship informs everyone about where the conversation to fix an issue happens, and the order of work to fix a group of issues.

• Duplicate: Bug X is the same as bug Y. The primary conversation about fixing the bug happens on bug Y. A secondary conversation happen on bug X. The affected projects, their status and importance, of bug X are identical to Bug Y.
• Dependency: Bug X depends on bug Y. Bug Y must be fixed before bug X can be fixed. The bugs have separate conversations, but each is informed of the other. Though the bugs have separate status and importance, there is some expectation that work proceeds from one bug to the next. As the bugs might affect different projects, the work to fix a bug may be done by different people. A project bug might depend on the fix in a library that is provided by another project. A bug in a distro series package might depend on the fix in an upstream project release. Dependency is implied when we see a bug that affects a distro package also affects the package’s upstream project.
• Similarity: Bug X and bug Y are caused by similar implementations. Bug X and Y require separate fixes that can happen concurrently. The bugs might share a conversation to find a fix, but the work and conversation is more often independent. In some cases, the proper fix is to create one implementation that the similar bugs depend on to fix the issue. A project might have two bugs caused by a bad pattern repeated in the code, or a pattern in one project is also used by another project. Each location of the pattern needs fixing. Maybe the right fix is to have a single implementation instead of multiple implementations.
• overlap: Fixing bug X  changes the scope of work to fix bug Y. These bugs have separate conversations, but the work to fix each issue needs coordination. Fixing one bug may make the other invalid, or make it more difficult to fix the other. Maybe these bugs need to be redefined so that they do not overlap? Maybe bug X can be fixed at the same time as bug Y? Maybe both bugs really depend on an unknown root cause…bug Z?

We might imagine the relationships like sets. The duplicate bug is a subset of the master bug. Two bugs intersect in the overlap relationship. Similarity is a superset of several bugs. The dependency relationship has a direction pointing from one bug to the next.

Managing separate conversations

People working with proprietary information create duplicate and or dependent bugs to manage separate conversations. The “Affect project”, “Affects distro”, and “Duplicate” action do not work because they either mix conversations, or loose status and importance. Users benefit when private conversations are split from public ones, but Launchpad does not help the user do this.

Launchpad will not permit projects to share the forthcoming “proprietary” bug information type. Proprietary information is given to one project in confidence; The project cannot share that information with another project. The “Affects project”, “Affects distro” cannot add projects to the bug, so Launchpad must help users report a separate bugs.

When someone realises a private bug affects more than one project, Launchpad could help the user split the bug into separate bug reports to manage conversations and the order of work to fix the greater  issue. Instead of adding a project or distro to the bug, the user might want to choose the project to report the bug in, and be prompted to revise the bug summary and description so that private information is not disclosed. The new bug is commonly public. It is the master bug, this is where the public conversation happens. This practice benefits more than the user who reported the bug…there is a public place for all users to discuss the issue.

Users are less likely to report a duplicate bug when Launchpad can show the public bug in the list of similar bugs. The principal cause of bug 434733 is not commercial projects, bug non-commercial projects like Ubuntu that mark bugs as duplicates of private bugs without consideration that users want to be informed and participate in the conversation.

Duplicate bugs continue to have separate side conversations that often focus on release issues. The discussion of how to fix the issue happens on the master bug. Duplicate bugs also have wasteful conversations that can be answered by the master bug. There is always a risk of disclosure when the reporter of a private bug has to visit the public bug to learn information that is pertinent to the private bug.  The risk and inconvenience could be avoided by showing the important information on the duplicate bug — do not force users to change the context when working with private data.

We can substitute another relationship for “duplicate” in my case for separating discussions. When a fix for a bug is dependent on a one or more other bug fixes, there are several conversations with different people with different concerns. The same is true for bugs with similar or overlapping concerns. The only time conversations really need to be shared is to coordinate the timing or scope of the fixes.

While privacy is a primary reason to split conversations, splitting public conversations can benefit as well. The current UI that encourages a single conversation of ambiguously related downstream and upstream projects is a source of unwanted email. If I am only interested in the issues that affect my projects, do not make be get email for all the other projects.  Splitting conversations into several bugs within a project is also a legitimate means to solve large problems that require different developers to fix code at different times. Minimising the notifications to just the relevant information keeps users focused on the issues.

Linking existing bugs

The workflow to select and link bugs is untrusted. When marking a bug as a duplicate, or linking a bug to a branch, Launchpad asks me to provide the bug number (Launchpad Id), then the page updates and I learn the consequences. Did I type the right number? Did people get emails about irrelevant or confidential information?

I expect Launchpad to ask me to review the bug I am linking and ask me to continue or cancel. Launchpad has to show enough information to answer my question’s and gain my trust:

• What is the bug’s summary?
• What is bug’s information type — is it private?
• Which projects does the bug affect?
• What are the bug’s tags?
• What is the bug’s description?

The presentation for bug listings provides most of this information. Launchpad could reuse the presentation (that I am already familiar with) when asking me to review the bug that matched the number I entered.

I imagine that if the action I am taking is specific, like marking a bug as a duplicate of another, Launchpad does not need to ask me about the relationship. In cases where the relationship is not implicit in the action, Launchpad must let me select the relationship between the bugs.

I know many users expect bug linking to work like selecting a user. They want to enter search criteria to see a listing of matches. The user might expand a match to see additional information. The user can select the bug, and maybe select the relationship to create the link. I am sceptical that this workflow would meet my needs. I often use advanced bug search to locate a bug; I cannot imagine offering advanced bug search in the small space to select a bug to link. The picker infrastructure that provides the workflows to select users and projects supports filters, which could be adapted to work with bug tags. I  doubt this will be very useful. Advanced bug search does not work well across multiple projects, and bug linking does and must work across projects. I think people will still needs to use advanced search to locate the bug that they want to link.

Presenting a summary of the bug relationships

When an issue is represented by several bugs, or a bug affects several projects, users need known how they relate to understand where and when someone needs to take action. Users often open many pages because Launchpad cannot summarise the relationships between several bugs. Users will also read through long comments to learn why a bug affects many projects.

When viewing a bug, the user needs to see a listing of related bugs (dependency, similarity, and overlap). The listing summarises the affected project, status, importance, assignee, and milestone.  Users might need to see bug tags, and badges for branches and patches. Maybe this is like the listing of bugs shown in bug search.

The affects table is a special bug listing. Does it need to be special? Users want to see the relationship between the items in the affects table. I want to know if the fix in a package depends on the fix in an upstream project. I am unsure how this could be done since there might be many relationships in the table. Maybe the many relationships, 3 or more affected project, packages, and series, will diminish when bug linking is available. We know that users unsubscribe when a bug affects many things because the conversation looses focus. When users can link bugs, there will be less needs to say a bug affects many things.

Privacy is a special case. A user can only see the relationship between two bugs if the user can see both bugs. When the listing contains private bugs, the presentation must call-out that they are seeing privileged information. Launchpad does not have a consistent way to show that part of a page contains private information.

• The user profile page will show locks before email addresses.
• Bug listings show a lock icon among other icons after the bug.
• Branch listings and linked branches show the lock icon after the branch.

Launchpad must make it clear to the user to not discuss the private relationships in the bug’s conversation.

Duplicates are presented differently from other bugs because they are subordinate to the master bug. There are several problems with the current presentation of duplicate bugs.

• Duplicate bugs show contradictory information in the affects table
• Duplicate bugs may not show the master bug if it is private
• Master bugs may show hundreds of duplicate bug numbers without summary or privacy information
• Why do I need to see all the duplicate bug numbers on a master bug?

Users do not need to see a list of all the duplicate bugs on the master bug. The number of duplicates is more interesting that a listing of numbers. User care about the duplicates they reported because they might want a side conversation, maybe Launchpad should show the user a link to the bug he or she reported? A contributor might want to read the the conversations in the duplicates for new information, so Launchpad does need to show a list of duplicates when the user asks for it. The listing of duplicates must indicate which are private. Other data like status and importance are irrelevant because the master bug provides the this information.

When I view a duplicate bug page, Launchpad must make it clear that this bug is a duplicate. I need to see the master bug’s information: affected project, importance, status, milestone, and assignee. I am not sure if the user should see its own affects table; that information would only be important if the bug was unduplicated.

There is a problem if the master bug is private and the user does not have permission to see the master bug. The user cannot see the master bug exists. Launchpad could prevent duplicate master bugs from being private if the project can have public bugs. In the case of projects with default proprietary bugs, the master bug will always be private. When the reporter of the duplicate bug cannot get information, he, and the project contributors are forced to start side conversations. Is it possible to show some of the affects table from the master bug to answer some of the user’s questions? May I know the status and importance of the master bug? May I know the affected project if both bugs have the same affected project?

Conclusion

The Launchpad team will spend about 12 weeks creating the bug linking feature. The feature will emphasise the use cases needed to support two other features in development now, sharing and private projects. Proprietary data has less need for revising the bug affects table, though a unified presentation of linked bug and affects projects might need less effort to create.

The essential points about bug linking is that project needs to manage bug conversations to mange the disclosure of private information. Organisations split work into multiple bugs to mange conversations and organise work between different people. Launchpad could show and summarise the linked bugs so that contributors do not need to switch context to plan work.

I think Launchpad is missing fundamental HTML, CSS, and JavaScript to support the three classes of browser with which someone might visit Launchpad. There are inconsistencies in pages you might visit, and some parts might not work because Launchpad does not have a “proven way” to solve a problem. I am most concerned about the rules of when something should be shown or hidden.

Launchpad intends to look good in graphical browsers, and gracefully degrade for textual browsers. Launchpad intends to be usable by everyone, and interactive browsers get enhanced features that makes the site easier to work with. We expect everyone who works with Launchpad regularly to use an interactive browser which provides information as needed and the best performance to complete a task. Essential tasks must be performable by textual browsers.

The three classes of browser Launchpad developers need to design for

Textual browsers convey all information with text, layout is less important and graphics are irrelevant. Textual browsers might be text-based browsers like W3m or Lynx, or it might be a screen-reader like Orca with a graphical browser. Textual browsers can also be bots, or even the test browser used by Launchpad’s test suite. All essential information must be expressible as text.

Graphical browsers use CSS-based engines to layout text and graphics in two dimensions. Chromium and Firefox are two of many browsers that might be used. Launchpad wants to use CSS 3, but it cannot be required since some browsers like Internet Explorer 8 use CSS 2. There is also the concern that all browsers have CSS and HTML bugs that require some care when crafting a page.

Interactive browsers support JavaScript to change the page content based on user actions. Again, Chromium and Firefox are two of many browsers that might be used, but a minority of users choose to use platform browsers like Internet Explorer, Safari, or Konqueror. Launchpad wants to use EcmaScript level 5, but will accept ES 3 with proper design.

Showing the essential, offering the optional, and hiding the unneeded

Consider the case for reporting a bug. This is an essential task everyone must be able to perform with the browser that they have available. Some steps in reporting a bug are optional, and might even be considered a distraction. Reporting a bug can take many minutes, but it can be made faster by showing or updating information at the moment of need.

Launchpad commonly makes links to add/report something like this:

<a class="sprite add" href="+action"></a>

The markup relies on CSS to show an icon in the background of the space allocated to the link. There is no text to convey the action is “Report a bug”. We have struggled to make this markup work in all browsers. I personally do not think this markup is legal. Anchors may be empty because they can have name attributes without href attributes. The HTML specification does not state an empty anchor with a href must be rendered. Older versions of webkit and khtml certainly do not render the sprite because there is no content to show. This markup is missing a description of what the link does.

Launchpad makes some links for its test browser that just happen to work brilliantly with textual browsers:

<a class="sprite add" href="+action"><span class="invisible-link">Report a bug</span></a>

Graphical browsers see an icon, and textual browsers see text. Well, this is not exactly true. Older webkit browsers do not show text or icon because there is no text to render. We use JavaScript to add an additional CSS class to the page so that a special CSS rules can add content before the hidden text to make the link visible. The “invisible-link” name is bad though, we do want the link visible, we just want a icon shown when the browser supports it. Like the previous example, graphical browsers still do not see a description of what the link does.

Launchpad commonly uses expanders to hide and show optional content. The blocks look something like this:

    <div class="collapsible">Options
        <div class="unseen">bug tags [ ]</div>
    </div>

Textual browsers can read the hidden content; they can set bug tags. Interactive browsers see “Options” and can reveal the content to set bug tags. Graphical browsers (or a browser where JavaScript failed) just see “Options”, it is not possible to set bug tags. The “unseen” CSS class could have been added after the script executed in the interactive browser to ensure it was hidden only if the browser could reveal it.

There is a problem with this example:

    <input id="update-page" class="unseen" type="submit" name="update-page" value="Update Page" />
    <img id="updating-content" class="unseen" src="/@@/spinner" />

Launchpad does not have classes that distinguish between interactive content that is “unseen” and graphical content that is “unseen”. The first line means interactive browsers cannot see the input element, and the second line means graphical browsers cannot see the img element. This ambiguity leads to cases where content that should be seen is missing, or vice versa.

Launchpad needs classes that mean what we intend

I image four classes are need to handle the cases for the three classes of browser.

readable

Textual browser can read or speak the content.
Graphical and interactive browsers to not show the content.
eg. links with sprites.

enhanceable

Textual and Graphical browsers can read, speak, and see the content.
Interactive browsers do not show the content, but can reveal it.
eg. expanders that show additional information or optional fields.

replaceable

Textual and Graphical browsers can read, speak, and see the content.
Interactive browsers do not see the content because it is superseded.
eg. forms that reload the page.

revealable

Textual and graphical browsers cannot read, speak, or see the content.
Interactive browsers do not show the content, but can reveal it.
eg. spinners that show loading in-page content.

The CSS classes need to interact with other classes on the page that help identify the class of browser:

readable

May need aural CSS to ensure it can be read and spoken.

enhanceable

No special properties needed.

enhanceable hidden

Scripts add the hidden class at the end of a successful setup because the content can be shown.

enhanceable shown

Scripts add the shown class at the end of a successful setup because the content can be hidden.

replaceable

No special properties needed.

replaceable hidden

Scripts add the hidden class at the end of of a successful setup because the content was replaced by interactive content.

revealable

The is not displayed because the browser must prove it can interact with it.

revealable shown

Scripts add the shown class at the end of a successful setup because the browser has demonstrated it can interact with the content.

Both the single “enhanceable” and “revealable” could be omitted because they are redundant with “enhanceable shown” and “revealable hidden”. I think the habit of placing classes that hide and show content in the page templates is dangerous. There are lots of cases where the page assumes a state before the class of browser is known. Page templates that use either “unseen”, or the  “hidden” class assume an interactive browser. It is not clear if textual and graphical browsers work by design, or by accident.

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.

Launchpad beta testers are seeing information types on bug reports. Launchpad replaced the private and security checkboxes with an information type chooser. The information types determine who may know about the bug.

When you report a bug, you can choose the information type that describes the bug’s content. The person who triages the bug may change the information type. Information types may also change as a part of a workflow, for example, a bug may start as Embargoed Security while the bug is being fixed, then the release manager can change the information type to Unembargoed Security after the release.

Testing in phases

In the first phase of this beta, Launchpad continues to share private information with bug supervisors and security contacts using bug subscriptions. The project maintainer may be managing hundreds of bug subscriptions to private bugs, and people are getting unwanted bug mail.

In the second phase of the beta, the project maintainer can share information types with people…the maintainer is only managing shares with a few teams and users and people are not getting unwanted bug mail.

Watch the video of information types and sharing to see the feature in use and hints of the future.

Launchpad beta testers will now see the descriptions of bug status and importance when making updates to the bug page. Launchpad pickers can now show the descriptions of the options you can choose.

Launchpad’s rules for defining a list of options you can choose have always required descriptions, but the only places you could see them were in some forms where they were listed as radio buttons. Bug status and importance where never shown as radio buttons, so their description were only know to people who read Launchpad’s source code. Users need to see the descriptions so that there is a common understanding of terms that allows us to collaborate.  The original bug importance descriptions were written in 2006 and only made sense for Ubuntu bugs. We revised the descriptions for the improved picker.

There has been a lot of confusion and disagreement about the meaning of bug statuses. Since users could not see the descriptions, we posted the definition on help.launchpad.net. Separating the status description from the status title did not end the confusion. We revised the descriptions for the improved picker, but I think we need to make more changes before showing this to everyone. The picker  appears to rely on colour to separate the choice title from description. Not all choices will have a special colour, and in the case of bug status there are two choices that appear to be the same grey as the description text:

The picker enhancements were made for the disclosure feature. We are changing the presentation of bug and branch privacy to work with the forthcoming project sharing enhancements. Early testing revealed that users need to know who will be permitted to see the private information when the bug is changed. This issue was similar to the long standing problem with bug status and importance. We decided to create a new picker that solved the old problem, that we could then reuse to solve the new problem.

I do not like the Launchpad branch page. It is rarely informative and I would like to ignore it, but there are a few tasks that I can only perform form that page. I think the page could be better if it were possible for me to state the branches’s purpose.

I sat down the Huw, the Launchpad team’s designer to discuss the page almost two years. He was struggling to make sense of the the branch page from a developer’s perspective. At that time I concluded that I disliked the page because it treats all branches as if they have the same needs, which ignores the fact that every branch has a purpose. A branch’s purpose determines what I need to know and what actions I can take. I saw two purposes at the time, but I recently concluded in a sleepless state that there are five purposes. Maybe this was a delusion created by the fever. Let’s see if I still think that at the end of this post.

The branch page is missing:

• A statement of intent
  What is the branch’s purpose? This determines the action I can perform and the information I need to see. Is this branch trunk, a supported series, for packaging, a feature, or a fix?
• A record of content
  I want to browse the files of some branches, while other branches I only care about the diff.
• A testament of accomplishment
  A branch’s purpose determines its goal. The goal of most branches is to merge with another branch. Some branched though must create releases or packages.

The features a branch needs are mostly determined by the how long the branch is expected to live:

• Short-lived branches
  The branch is often based on trunk, its purpose is to fix or add a feature (Bug or blueprints), and it goal it is to merge into its base branch.
• Long-lived branches
  The branch is often the basis of other work. It is the sum of many merges, often summarised as milestones. The goal of the branch is to create releases.

Trunk branch

The most important branch to every project is the one designated to be trunk. This branch will live for months, or years. This is the branch I use as the basis for my changes. It is the goal of most derived branches to merge with this branch. The goal of trunk is to make releases.

There is no need to show me which bugs are fixed or blueprints (features) are implemented in trunk. Trunk is everything to the project. When we say there is a bug in a project, we really know that bug is in trunk. Launchpad could change how it models bugs to make this case clear. The bug tracker or specification tracker are the only tools that can adequately explain which bugs and blueprints were closed. I might be interested in which bugs and blueprints were recently fixed in trunk though.

The merge action does not make sense. It is the goal of other branches to merge with trunk…trunk does not merge with other branches! Well this is not entirely true in the packaging case, which I will explain shortly. I am interested is seeing the list of recently proposed merges into this branch. The branch log shows me which branches were merged.

I want Launchpad to shown me the bugs and blueprints that the project drivers plan to fix. Will my bugs be solved soon? Can I contribute? Launchpad actually can show me this on the series page. Launchpad separates the concept of planning changes (feature and fixes) from branch. There is good reason for this, but the separation of information creates a chasm that many developers fail to cross.

We commonly organise change into milestones, and each milestone may culminate in a release. A series of milestones represent continuity and compatibility. Distributions have a series without having a trunk branch. There are also projects that do not produce code, but have bugs and blueprints. Launchpad is also a registry of projects and releases that are packaged in Ubuntu.

Launchpad creates a trunk series for every registered project because we believe all projects should state their intent and distinguish between different bases of code. But where is the code? Where is my branch? I commonly see projects with series information without a branch, and I commonly see projects without series information, with tremendous branch activity. It is difficult to contribute when you cannot see what is happening and what needs to happen. Project maintainers are equally frustrated; Launchpad is not helping them to create releases from their trunk branch.

Launchpad asks me to link a branch to a series, but I think most developers want to state that their branch is the trunk series, or is a supported series. The branch is elevated to a new role and it gets the features that the role needs. I want one page about the trunk branch, not a page about planning and a page about branch metadata.

Supported series branch

A supported branch represents a previous project release. It is a historic version of trunk with its own bugs and features. Like trunk, the linked bugs and branches do not make sense, nor do I want to merge a supported branch into another branch. A supported branch can live for months or years. Some fixes (branches) will be merged into the support branch. Feature branches are never merged into supported branches.

In the case of a supported branch, I most want to know the milestones/releases that represent the life of support. I want to know which fixes in trunk will be backported to the supported branch. I might be interested in knowing the fixes (branches) that were recently merged.

Packaging release branch

A packaging branch contains additional files needed to create an installable package from a project’s release. A packaging branch often has counter-part branch, usually a supported branch, but sometimes trunk. Thus the packaging branch lives for months or years. The packaging branch may only contain the extra files to create a package using a nesting recipe, or it contains repeated merges of the counter-part branch. I am only interested is seeing the differences from the counter-part branch. I do not want to browse all files in the branch.

Packaging branches have their own set of bugs — the files introduce bugs and yet some of the patch files fix bugs in the counter-part branch. Thus we might image that the packaging branch is the sum of the bugs in the supported and packaging branch, minus the fixes provided by patches.

Packaging branches are often managed by different people from the project’s developers. Their skills and permissions are often different too. A patch to expediently fix a bug in the packaging branch might take much longer merge into the supporting branch where the bug originates.

Feature (blueprint) branch

A feature branch adds new functions to the code. It is short-lived, measured in days or weeks. The branch is based on trunk and is goal is to merge with trunk.

Feature branches need all the features that the current branch page provides. The feature branches has blueprints that specify what functions are being added and the criteria to know when the feature is done. They may also fix bugs. A recipe can be used to build an unstable package for testing.

Merges are far more complex for feature branches than is implied by the Launchpad’s UI. There are many workflows where a feature branch is actually composed of several branches that might be merged with trunk individually, or they are merged as a whole when the feature us deemed stable. Launchpad should encourage me to merge the branch into trunk, merging into another kind of branch doesn’t make sense. The UI does not properly show that I may merge my feature branch into trunk several times, or that several branches might merge into my feature branch.

I am only interested in seeing the changes from trunk. I do not want to browse all the files in the branch. Since a feature branch can be composed of many branches, I want to see the difference between the merges to understand the revision changes.

Fix (bug) branch

A Fix branch exists to close a bug. The branch is short lived, measure in hours or days. Its goal is to merge with its base branch. The older the branch gets, the more likely that it has failed.

It does not have related blueprints or recipes. I am not interest on seeing all the files and code in the branch; I only care about the changes from base.

A fix branch needs to tell me which bugs it fixes. It must encourage me to merge the fix back into the base branch.

Most fixes are based on trunk and will merge with trunk, but when a bug also affects a supported branch, Launchpad might want to encourage me to propose a backport. Launchpad currently allows me to nominate/target a bug to a series (which is ultimately a branch) when there is no fix. I think this is odd. Project development is focused on trunk, fixes are almost always made in trunk first. Once trunk has the fix, it is possible to determine the effort needed to backport it to a supported branch. If a bug is only in a supported branch, then I think it is fine for Launchpad to allow me to nominate it to be fixed, which implies the fix is already in trunk.

Conclusion

Hurray! I still think there are five kinds of branches which different needs. This issue is like a bad word processor which treats a letter, a report, and a novel the same. A good word processor knows the document’s intent and changes the UI and available features so that I can complete my task without distraction. The current branch page emphasizes what all branches have in common, but it needs to emphasise the differences so that I know what I need to do. There are no plans to change the branch UI, but contributors are welcome to improve Lp. I hope my thoughts will contribute to a proper analysis of features the branch page must support.

Setting up a commercial project in Launchpad has gotten easier. You can now quickly register a proprietary project and enable private bugs. You can create private teams and private personal package archives, AKA private PPA or P3A without the assistance of a Launchpad admin.

When you select the Other/Proprietary license while registering a project, or changing the project’s details,

it is given a complimentary 30-day commercial subscription.

The delay between the moment when a commercial project was registered and when the commercial subscription was purchased and then applied to the project caused a lot of confusion. During this delay, proprietary data could be disclosed. We chose to award the project with a short term commercial subscription which enabled the project to be properly configured while the 12-month commercial subscription was being purchased and applied to the project.

Any project with a commercial subscription can enable

Default private bugs

Once enabled by configuring the project’s bug tracker, all new reported bugs are private. You can choose to make the report public.

Default private branches

You can request a Launchpad admin to configure private branches for your teams. (You will be able to do this yourself in the near future when projects gain proprietary branches.)

As the maintainer of a project with a commercial subscription, you can register

Private teams

When you register a team, you can choose to set the team visibility to private. The team’s members and data is hidden from non-members.

Private mailing lists

When you create a mailing list for a private team, the archive is also private. Only team members may see the messages in the archive.

Private PPAs

When you create a PPA for your public team, you may choose to make it private; private teams can only have private PPAs. You can subscribe users to your archive so that they may install packages without revealing all your team’s members and data to the subscriber.

A secondary benefit of this change is that you can now try Launchpad’s commercial features before purchasing a 12-month commercial subscription. The features will be disabled at the end of 30-days. Your test data will remain private to ensure your data is not disclosed.

Any open source project may also have a commercial subscription to enable commercial features. You can purchase a commercial subscription at the Canonical store. Commercial subscriptions cost US$250/year/project + applicable V.A.T.

(Photo by Fred Dawson on flickr, creative commons license)

I have been looking for an easy and reliable way to develop and test Launchpad with Internet Explorer. Neither of the two common approaches used by Ubuntu users allows a Launchpad developer to  easily verify that a change works with Internet Explorer. The challenge is to install a working version of Internet Explorer 8 and browse the local development instance of Launchpad. Maybe you can help me find a way to do this?

While Internet Explorer only represents 4% of Launchpad users, recent changes to make Launchpad easier to use made many tasks for IE users impossible to complete. This was unintended. It is a regression, and we treat all regressions as critical issues. The Purple squad reviewed the code and found that a lot of Launchpad JavaScript is disabled for all versions of Internet Explorer without an explanation nor fall-back behaviour. There is no documented way to ensure Launchpad works with Internet Explore, so most developers do not try to make it work.

Microsoft’s developer image of Windows 7 + IE8

Microsoft provides many images of Windows and IE so that Web developers can ensure their code works. The images are compatible with VirtualBox. The installation of the required software is easy, though configuration is tricky. The greatest challenge is creating a reusable Apache2 config for the many Launchpad domains.

Microsoft provides VPC compatible IE images to anyone who wants to verify that a website works with a specific version of IE. You will need about 13GB of disk space to install and run this bloatware that we all have come to expect with Windows. I installed the needed software using these commands:

$ cd /path/to/lots/of/disk/space/VirtualBox/HardDrives

$ sudo apt-get install virtualbox unrar curl

$ curl -L -O "http://download.microsoft.com/download/B/7/2/B72085AE-0F04-4C6F-9182-BF1EE90F5273/Windows_7_IE8.part0{1.exe,2.rar,3.rar,4.rar}"

$ unrar e Windows_7_IE8.part01.exe

I started VirtualBox and changed the preferences to use the path where I had lots of disk space. I created a new Windows 7 instance using the virtual disk. The disk had to be mounted as IDE (SATA failed) and the network was set as bridged.

IE worked perfectly with Ubuntu’s SSO. I could use Launchpad as I expected. In the cases where I expected a problem, I could see behaviours that confirmed my suspicion about the nature of the defect. This setup is ideal for verifying changes on Launchpad’s qastaging and production servers.

Making this setup work with the Launchpad development instance was very difficult. I hard-coded IP addresses to ensure that Windows and Apache knew the *.launchpad.dev sites. My IP address on my local network was 192.168.1.7 at that moment.

• Windows: Added
  c:\windows\system32\drivers\etc\hosts
  which contained
  192.168.1.7 testopenid.dev launchpad.dev code.launchpad.dev answers.launchpad.dev blueprints.launchpad.dev bugs.launchpad.dev translations.launchpad.dev
• Ubuntu: Copied
  /etc/apache2/ssl/launchpad.crt
  to a device that I could mount in Windows [1]
• Windows: Added the launchpad SSL certificate to the Trusted root certificate store
  Internet Options → Content → Certificates → Trusted Root Certification Authorities
• Ubuntu: Updated all references in
  /etc/apache2/sites-enabled/local-launchpad
  of
  127.0.0.88
  to
  192.168.1.7
• Ubuntu: Added
  Allow from 192.168.1.*
  after all occurrences of
  Allow from localhost 127.0.0.0/255.0.0.0

I could login but I discovered that I occasionally needed to rearrange the entries in the Windows hosts file because it has a character limit! Every time my computer’s IP address changes, I need to update the Windows hosts file and the Ubuntu Apache config. I do not mind editing my IP in the Windows host file, but I do not like editing the entries or updating the Apache config. I doubt this setup works for developers using LXCs or other VMs to run Launchpad. I am planning to switch to LXC when Precise is released so this solution may not work for me in a few weeks.

Wine + Winetricks + IE8

Winetricks is a tool that can install and configure IE8 so that it runs on Ubuntu. Installation is very easy, but the UI’s controls and menus are broken. The greatest challenge is that the security behaviour is different from real Windows and IE — the browser thinks real Ubuntu SSO and the entire Launchpad development site is insecure so does not send the required REFERER header.

I installed the needed software using these commands:

$ sudo apt-get install wine winetricks
$ winetricks corefonts ie8

Configure Wine to work with launchpad development instance:

• Add the Launchpad SSL certificate to Wine [1]
  $ wine control
  Internet Settings → Content → Certificates → Trusted Root Certification Authorities
• Run IE
  $ wine iexplore

The UI does not look like IE8, and the broken buttons and menus certainly do not lend any confidence that this works. I can see from the Apache log that my request to https://launchpad.dev/claims to be MSIE 8. I cannot login to the website though. I can see in the logs that the REFERER header was not sent, so the post was rejected. The same is true for posting to the real Ubuntu SSO and Launchpad website — all posted forms fail. IE does this when it believes the browser is posting across a security boundary; it is protecting the user. Since the real Windows 7 + IE8 does not see either the development or production instance as unsecure, I know that something is misconfigured in Wine. I believe the SSL was install correctly because the real IE8 accepted it as did my Ubuntu browsers.

I can make the Launchpad development instance work with the broken Wine IE8 by hacking lp.services.webapp.publication to not requiring the REFERER header for MSIE 8 when the launchpad instance’s host end with “.dev”. This permits me to verify that JavaScript works, but is it really verifying that real IE8 works? I have no confidence in this hack. What else is broken in the setup?

[1] The default Launchpad SSL certificate in the Launchpad tree that is installed by rocketfuel-setup is incomplete. I generated a certificate that properly specified the sites it was for. I installed the better certificate in /etc/apache2/ssl and in my local OpenSSL store. The immediate benefit is that all of my development browsers accept the SSL certificate; not warning about wrong domains. I will add the better certificate to the Launchpad development tree and the script I used to generate and install it.

Launchpad can now show you all the people that your project is sharing private bugs and branches with. This new sharing feature is a few weeks away from being in beta, but the UI is informative, so we’re enabling this feature for members of the Launchpad Beta Testers team now. If you’d like to join, click on the ‘join’ link on the team page.

What you’ll see

Project maintainers and drivers can see all the users that are subscribed to private bugs and branches. The listing might be surprising, maybe even daunting. You may see people who no longer contribute to the project, or people you do not know at all. The listing of users and teams illustrates why we are creating a new way of sharing project information without managing bug and branch subscriptions.

If you’re a member of (or once you’re a member of, if we want people to join) the Launchpad Beta Testers team, you can find the Sharing link on the front page of your project. I cannot see who your project is sharing with, nor can you see who my projects are sharing with, but I will use the Launchpad project as an example to explain what the Launchpad team is seeing.

The Launchpad project

The Launchpad project is sharing private bugs and branches with 250 users and teams. This is the first time Launchpad has ever provided this information. It was impossible to audit a project to ensure confidential information is not disclosed to untrusted parties. I still do not know how many private bugs and branches the Launchpad project has, nor do I even know how many of these are shared with me. Maybe Launchpad will provide this information in the future.

Former developers still have access

I see about 30 former Launchpad and Canonical developers still have access to private bugs and branches. I do not think we should be sharing this information with them. I’m pretty sure they do not want to notified about these bugs and branches either. I suspect Launchpad is wasting bandwidth by sending emails to dead addresses.

Unknown users

I see about 100 users that I do not know. I believe they reported bugs that were marked private. Some may have been subscribed by users who were already subscribed to the bug. I can investigate the users and see the specific bug and branches that are shared with them.

The majority

The majority of users and teams that the Launchpad project is sharing with are members of either the Launchpad team or the Canonical team. I am not interested in investigating these people. I do not want to be managing their individual bug and branch subscriptions to ensure they have access to the information that they need to do their jobs. Soon I won’t have to think about this issue, nor will I see them listed on this page.

Next steps — sharing ‘All information’

In a few weeks I will share the Launchpad project’s private information with both the Launchpad team and the Canonical team. It takes seconds to do, and about 130 rows of listed users will be replaced with just two rows stating that ‘All information’ is shared with the Launchpad and Canonical teams. I will then stop sharing private information with all the former Launchpad and Canonical employees.

Looking into access via bug and branch subscriptions

Then I will investigate the users who have exceptional access via bug and branch subscriptions. I may stop sharing information with half of them because either they do not need to know about it, or the information should be public.

Bugs and private bugs

I could start investigating which bugs are shared with users now, but I happen to know that there are 29 bugs that the Launchpad team cannot see because they are not subscribed to the private bug. There are hundreds of private bugs in Launchpad that cannot be fixed because the people who can fix them were never subscribed. This will be moot once all private information in the Launchpad project is shared with the Launchpad team.

Unsubscribing users from bugs

Launchpad does not currently let me unsubscribe users from bugs. When project maintainers discover confidential information is disclosed to untrusted users, they ask the Launchpad Admins to unsubscribe the user. There are not enough hours in the day to for the Admins to do this. Just as Launchpad will let me share all information with a team or user, I will also be able to stop sharing.

(Image by loop_oh on flickr, creative commons license)

We are reimagining the nature of privacy in Launchpad. The goal of the disclosure feature is to introduce true private projects, and we are reconciling the contradictory implementations of privacy in bugs and branches.

Launchpad will use policies instead of roles to govern who has access to a kind of privacy

We are implementing three kinds of policies, proprietary, embargoed security, and user data. The maintainer is the default member of these policies. The maintainer can share a kind or private data by adding a user or team to a policy.

For proprietary projects, the maintainer can add their organisational teams to the proprietary policy to share all the project information with the team members.

For Ubuntu, the maintainer will set the apport bot to be the only user in the user data policy; user data is only shared with a bot that removes personal data so that the bug can be made public. The Ubuntu security team will be the only users in the security policy.

Most maintainers will want to add project drivers to the policies if they use drivers. Bug supervisors can be added as well, though the team must be exclusive (moderated or restricted).

You can still subscribe a user or team to a private bug or branch and Launchpad will also permit the user to access it without sharing everything with the user. The existing behaviour will continue to work but it will be an exception to the normal rules.

Polices replace the bug-subscription-on-privacy-change rules. If you have every had to change the bug supervisor for a project with many private bugs, you can rejoice. You will not need to manually update the subscriptions to the private bugs to do what Launchpad implied would happen. Subscriptions are just about notification. You will not be notified of proprietary changes is proprietary information is not shared with you. Sharing kinds or information via policy means that many existing private bugs without subscribers will finally be visible to project members who can fix the issue.