launchpadblog

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)

At its most basic, a blueprint in Launchpad is a statement of intent: by creating a blueprint, you’re saying, “Here’s an idea for how this project should progress.”

How do you track the detailed steps to get from having the idea to seeing it implemented?

The Ubuntu development community came up with a solution: they break a blueprint down into items of work that can be assigned to an individual. That makes it easier to track who’s doing what and how they’re getting on, while the blueprint itself tracks the status of the big idea.

Until now, these work items weren’t recognised by Launchpad. Instead, Ubuntu and Linaro tracked them in the blueprint’s whiteboard. Using the Launchpad API, they pulled the whiteboard contents out and used them to generate burn-down charts for status.ubuntu.com and status.linaro.org.

Now, thanks to work by some of the team at Linaro, each blueprint has a text box where you can add, update and delete its related work items.

How you make use of work items will depend on the project you’re working on. Both Ubuntu and Linaro already make extensive use of work items and, if you’re working as part of those communities, you should follow their lead.

Using work items

Work items are pretty simple to use.

Here’s an example of how a set of work items might look:


Design the user interaction: DONE
Visual design: INPROGRESS
Test the UI: TODO
Decide on an API format: POSTPONED
Bootstrap the dev environment: TODO
Set up Jenkins CI: TODO
As you can see, each work item sits on its own line and you indicate its status after a colon.


As you can see, each work item sits on its own line and you indicate its status after a colon. The statuses you can use are:

• TODO
• INPROGRESS
• POSTPONEDDONE

Sometimes a blueprint can be targeted to one milestone but you’ll have a individual work items that need to be targeted to a different milestone. That’s fine, you can tell Launchpad that a bunch of work items are for some other milestone.

In the work items text box, simply use a header like this:


Work items for <milestone>:


If you enter an invalid milestone you’ll get an error message and the opportunity to correct the text field.

A milestone picker will of course be more useful and we’ve submitted a bug to keep track of that.

What’s next?

Soon, you’ll be able get a view of all the work items and bugs assigned to a particular individual or team for a particular milestone.

Of course, if you have other ideas for how Launchpad can make use of work items, we’d love to hear from you.

Photo by Courtney Dirks. Licence: CC BY 2.0

Two changes to the contact team email feature were recently released that make communication more reliable.

Non-team members now see the “Contact this team’s admins” link. Previously, non-members saw a link to contact the team owner. The owner is often one person, and some team owners delegate the running of the teams to the team admins. There are often more admins then there are owners. So the message is more  likely to reach someone who is involved in the day-to-day team management.

Team members see the “Contact this team’s members” link. Previously, members might have seen a link to contact the team, but that email when to the team email address that the team might not respond to. Many teams still use bogus email addresses to avoid emails from the days before Launchpad had great bug subscription filters. Launchpad has an anti-feature that prevents team mailing-lists from contacts all the team members. Team admins found it impossible to notify the member about issue ranging from policy changes, polls, meetings, to security issues. So members can now trust that their messages will be sent to the team members.

The feature is a convenient way to contact a user or team. Sometimes the feature is the only way you can contact a user or team that does not have a public email address. A user may use the contact user/team feature 3 times each day. The limit ensures no one can spam Launchpad users. The limit also means the feature is not a substitute for mailing lists.

The title may sound like a contradiction, but I assure you that it is not. You can now use private teams in social contexts in Launchpad. Private teams can collaborate with public projects and other teams if they choose to reveal the existence of the private team.

1. Private teams can me members of other teams.
2. Other teams can be members of private teams.
3. Private teams can subscribe to bugs, blueprints, branches, and merge proposals
4. Private teams  can be in public project roles,  such as maintainers, drivers, and bug supervisors.
5. You can change the branch owner to be a private team.
6. Private team personal branches (+junk) are always private.

When a member places the private team in a social situation, a the member is asked to confirm that it is okay to reveal the team’s identifying information. This information is the team’s Launchpad Id used in URLs, the displayname, icon, and logo. A user can visit the private team’s Launchpad page and will only see that information. The rest of the page is not shared. Anonymous users cannot see a private team’s page because that user is not being social; logged in users can see the private team’s page

Private team page seen by a non-member

Launchpad did not permit these interactions previously because it was not clear who should know about the team. Someone has to know. If Launchpad permitted private teams to subscribe to bugs or be members of teams without anyone knowing of them, they would be unaccountable. Private teams could spy on organisation, or learn about security vulnerabilities to exploit. Launchpad will not ever permit such asocial behaviour. The resolution for social interactions was to permit other parties to know enough of the private team to make an informed decision. For example, when I choose to make a bug private, I want to know who was already seen the bug through a subscription. I may choose to unsubscribe the private team if I do not trust them.

Private teams may invite exclusive teams to be members. Exclusive teams (moderated or restricted teams) review all members so they are accountable. If a team admin trusts the admins of another team, and that team is accountable, Launchpad permits the other team to be a member. This is actually a rule that applied to all exclusive teams. private teams are always exclusive (restricted membership policy). The only nuance with private teams is when it is a member of another team; the super team may know the members of the private sub team because the super team has the right to audit all its members so that it too can be accountable.

We’ve just upgraded Launchpad’s builder machines to Bazaar 2.4. Most importantly, this means that recipe builds of very large trees will work reliably, such as the daily builds of the Linaro ARM-optimized gcc. (This was bug 746822 in Launchpad).

We are going to do some further rollouts over the next week to improve supportability of recipe builds, support building non-native packages, handle muiltiarch package dependencies, improve the buildd deployment story etc.

We’ve recently deployed two features that make it easier to find bugs that you’re previously said affect you:

1: On your personal bugs page, there’s now an Affecting bugs that shows all these bugs.

2: On a project, distribution or source package bug listing page, there’s now a “Bugs affecting me” filter on the right (for example, bugs affecting you in the Launchpad product).

Counts of the number of affected users already help developers know which bugs are most urgent to fix, both directly and by feeding into Launchpad’s bug heat heuristic. With these changes, the “affects me” feature will also make it easier for you to keep an eye on these bugs, without having to subscribe to all mail from them.

If you use gmail, you should now be able to send commands to Launchpad without gpg-signing.

gmail puts a DKIM cryptographic signature on outgoing mail, which is a cryptographic signature that proves that the mail was sent by gmail and that it was sent by the purported user. We verify the signature on Launchpad and treat that mail as trusted which means, for example, that you can triage bugs over mail or vote on merge proposals. Previously you needed to GPG-sign the mail which is a bit of a hassle for gmail.

(DKIM is signed by the sending domain, not by the user, so it doesn’t inherently prove that the purported sender is the actual one. People could intentionally or unintentionally set up a server that allows intra-domain impersonation, and it’s reported to be easy to misconfigure DKIM signers so that this happens. (Consider a simple SMTP server that accepts, signs and forwards everything from 192.168/16 with no authentication.) However, in cases like gmail we can reasonably assume Google don’t allow one user to impersonate another. We can add other trusted domains on request.)

If you have gmail configured to use some other address as your From address it will still work, as long as you verify both your gmail address and your other address.

You can use email commands to interact with both bugs and code merge proposals. For instance when Launchpad sends you mail about a new bug, you can just reply

  status confirmed
  importance medium

Thanks for letting us know!

We do this using the pydkim library.

Note that you do need at least one leading space before the commands.

If you hit any bugs, let us know.

As of recently, you have more control of what email Launchpad sends you about bugs.

Instead of bug subscriptions being all or nothing, you can now tell Launchpad exactly what bug-related events you want to hear about. And if you find you’re getting too much, or too little, detail you can change your subscription at any time.

What’s more, it’s now easier to filter the bug mail that Launchpad sends you.

Subscribing to an individual bug

Let’s take a look at a bug report about Gwibber. Over on the right-hand side is the Subscribe link as usual. Clicking on it, though, gives us three new options for when Launchpad should email you about this bug:

• a change is made to this bug or a new comment is added
• any change is made to this bug, other than a new comment being added
• this bug is fixed or re-opened.

You get to choose how much detail you want about the life of this bug, from receiving an email about everything through to Launchpad notifying you only when the bug is fixed or subsequently re-opened.

Editing a subscription to an individual bug

You can change your mind about your bug subscription. Simply click the Edit subscription link that appears once you’ve subscribed.

You get the same options, along with an additional option of unsubscribing entirely.

Subscribing to a project

You’ve been able to subscribe to all the bugs in a particular project or distribution (and milestone, series, packages within those) for a few years now. However, for anything but the quietest of projects this could bring a new intensity to the phrase “drinking from the fire hose”.

Now you can have sane subscriptions to these broader structures within Launchpad. Let’s subscribe to bugs in OpenStack to see how it works.

Clicking Subscribe to bug mail on OpenStack’s bug overview page gives allows you to:

• subscribe yourself or one of your teams
• name the subscription — this gets added to the emails that result
• choose whether you want to hear when a bug is opened or closed, or if you want to go into more detail.

So, now you have a subscription called OpenStack overview that’ll generate an email whenever a bug report is opened or closed in OpenStack.

Refining a project subscription

Let’s say you’re particularly interested in OpenStack documentation. No problem, you can keep your OpenStack overview subscription for everything else and add a more detailed subscription just for documentation bugs.

If that’s not enough, you can also filter by importance and status.

Muting bugs

If a particular bug becomes too noisy, you can mute it. No matter how you’re subscribed to that bug — even if you have several subscriptions that generate email about that particular report — once you’ve muted it, you won’t hear about that bug again.

Of course, you can unmute it any time you like.

Unsubscribe in anger

At the bottom of every bug mail that Launchpad sends you’ll now find a link to edit your subscriptions to that bug. So, no matter how how you’re subscribed to the bug you’ll find all those subscription listed on that page and have the option to edit each of them.

You can also get to that page by clicking Edit bug mail on the bug page itself.

And there’s more

To help with filtering, Launchpad now adds a new header to bug emails:

X-Launchpad-Subscription

It quotes the name you gave the subscription when you created it. For Gmail users, all bug emails also feature the subscription name in the footer of the email body.

And don’t forget that you can already opt-out of email about your own actions on bugs and Launchpad won’t send email about quickly corrected mistakes.

I know I’m going to find bug mail easier to deal with now. Congratulations to the Yellow Squad on delivering this feature!

Launchpad has quite a few background tasks that update things outside of your browser request, and the only way you know that they finished is to reload a page to see if it changes.

Updating the preview diff on a merge proposal is one example.

At our Launchpad sprint in Dublin a couple of weeks ago, we added a so-called “long poll” where the browser opens a long-running connection using XHR (a background Javascript connection) to a new piece of infrastructure called the “long poll server”

This server is something that the Landscape team originally wrote and we’ve now open-sourced it so we can use it in Launchpad. The server connects to a RabbitMQ instance and relays information back to the browser when the background task completes so that the user doesn’t need to keep reloading the page – the page will automatically update thanks to the magic of Javascript.

The proof-of-concept is done but we now need to make it work in our production environment, which means making it more reliable, configuring the deployment and add some stats collection so we can see how it behaves. We’ll start off by only letting a small subset of people use it and grow it over time until we consider it stable enough for all users.

Photo by Jay Gooby. Licence: CC BY 2.0

Over the past few months, my team have been working to make it easier to create and manage derivative distributions in Launchpad.

Although most of this will be of interest only to distro admins and contributors, we recently released a beta of a new feature that lets you visualize the differences between Ubuntu’s Oneiric series and Debian Sid.

There’s a new portlet on the distroseries page that will list the numbers of packages in both distributions, numbers only in Sid and numbers only in Oneiric. Clicking on the links takes you to pages that show the differences in more detail and allows you to request debdiffs and add comments on the packages.

Please let me know what you think of this change. We’re tracking bugs using the ‘derivation’ bug tag. Note that this is not meant to be a replacement for MoM – yet. We have a long way to go for that.

Coming soon, actual syncing from Debian to Ubuntu. Watch this space!