launchpadblog

We heard from Ubuntu maintainers and upstream developers that it was too easy to lose track of patches in bugs filed on Launchpad — or, put another way, that Launchpad wasn’t doing enough to bring patches to developers’ attention.

According to the Launchpad Upstream Improvements Spec that came out of a recent UDS:

Upstreams frequently complain that it is difficult for them to find Ubuntu patches. patches.ubuntu.com is a diff between Ubuntu and Debian, so it’s not really useful to some upstreams. We want an upstream patch report that shows patches in packages and their age, so we can act on them. …

To help solve this problem, we’ve added two new features to Launchpad.

1. The upstream report now shows bugs carrying patches.

The upstream report now shows the number of bugs carrying patches — see the rightmost column in this screenshot:

(click image to enlarge)

If you click on the number in that column, it brings you to a listing of the bugs with patches.

2. A new “patch report” is available wherever bugs are available.

The second feature is a new patch report available for projects, project groups, source packages, people, teams, distributions, and distroseries. It lists bugs that have patches attached — for those of you who’ve seen Bryce Harrington’s mockup, this is the same thing implemented directly in Launchpad.

The goal of the patch report is to make it easier for packagers and upstream developers to find patches that could be upstreamed, and, especially, to enable them to evaluate those patches quickly.

You can reach the patch report from a new link on any bugs page. On the project bugs page below, for example, see the link “7 bugs with patches” in the portlet on the right (and you can click on any of these screenshots to get a larger version):

Clicking on the “7 bugs with patches” link appends “+patches” to the URL (hint, hint) which takes you to the corresponding patch report. There, patches are listed by bugtask, sorted by the age of the most recent patch in each bug, on the theory that new patches are probably more interesting than old ones:

But you can sort by other things as well — say, by bugtask importance:

Sorting applies across all applicable patches, not just the ones that happen to be on the current page of a potentially multi-page list. Thus changing the sort order might change the set of bugs visible on the current page:

When you hover over a patch, a popup shows details about that patch (who uploaded it, the patch’s filename, and its attachment message):

The patch report for entities like distributions and distroseries arranges patches by source package, since the same bug may have a different bugtask for each package, and each bugtask may have its own status, importance, etc:

You can also view the patch report on a particular source package:

Note that distroseries, persons, teams, and project groups all support this feature too. I didn’t include screenshots for them, to save space, but their patch reports can be reached in the expected way.

Naturally, clicking on a patch takes you straight to the diff:

We’re hoping that these features, combined with the recently-landed patch notification improvements and bug heat, will make it easier to find the patches worth immediate attention.

These patch reports are new in Launchpad 10.02. About a month after they go live, we’re going to look at the stats on how people have been using them, and we’re going to survey some upstreams and Ubuntu maintainers to see what they feel can be improved. Please also file bug reports as you use these new features, of course (if you feel like going the extra mile, tag your bug report with the patch-tracking tag — it’ll save us some time).

Finally, please feel free to help improve the features yourself! The bug links below will lead you to the branches on which these changes were made, so you can see what the code looks like. The Launchpad development wiki is the place to start for hacking on Launchpad.

References:

• Launchpad Upstream Improvements Spec

• The Bugs/PatchTracking page in the Launchpad Development Wiki

• Bug #283097 is about adding a ‘has patch’ column to the +packagebugs page.

• Bug #283941 is about showing patches in the upstream report (see linked branch for code change).

• Bugs tagged with story-patch-report are about the patch report (again, see linked branches for code changes).

Things we didn’t get to this cycle, but that we’re thinking about:

• Finding patches in other distributions (but see Daniel Holbach’s amazing Harvest tool).

• Bug #515674 is about showing the patches a distribution is carrying in its packages (i.e., in its debian/patches directories). Note in particular comment #4 there, about UI complexity.

• Showing patches in upstream trackers. Such patches might be downstreamable, or they might be the same as patches Launchpad already has; either way, it’d be good to know. See bug #403443.

• Package ↔ Branch equivalence. Really, a branch attached to a bug is equivalent to a patch attached to a bug (assuming the base source can be easily located, which it often can be). Ideally, we could represent either one as the other, and treat them as the same in filters and reports.

• Launchpad isn’t yet making use of the Debian DEP-3 Patch Tagging Guidelines metadata, which is also the standard in Ubuntu now.

• In general, see bugs tagged with patch-tracking and patch-tracking-external.

Ascertaining the importance of a bug can be one of the harder parts of bug triage, right?

It’s no problem if the project’s relatively small and you’re intimately involved with each bug but if you’re helping to triage for a larger project, it’s not always that easy.

To help, we’ve introduced a new indicator of how hot a particular bug is. A bug’s heat is a calculated estimate of its importance, using factors such as how many people are subscribed, whether it’s a security issue, how many people have marked the bug as affecting them, and so on. Note that it is not a replacement for the bug’s human-set importance but rather an aid to the people deciding what the importance should be.

You can see the full details of how bug heat is calculated on our wiki page.

A bug’s heat is shown on the bug report page as four flame icons. The hotter the bug, the more of the icons are lit. You can also sort bug search results by bug heat.

There’s a bug at the moment that means there’s a fairly high barrier for a bug report to jump before any of its flames light up but take a look at the Ubuntu bug list, sorted by bug heat, and you’ll see the new bug heat icons in action.

Let us know how you’d like to use bug heat.

There are a couple of new features related to patch handling in Launchpad bugs this month.

Building on the work we did in December to better distinguish patches in bug pages, we now use an icon to show if a bug has a patch attached in bug listings.  Any search on Launchpad will now indicate if a bug has a patch attached.  Look for the band aid icons, and you’ll know that a bug has a patch attached.

Also, bug mail notifications have been updated to distinguish patches from any other attachment.  Now when a patch is added or removed from a bug the email notification will read “Patch added” or “Patch removed” to make spotting patches easier in email.

These are small improvements to our handling of patches to help patches become more easily spotted on Launchpad.  Combined with our work on sorting bugs by a heat number, the Launchpad bugs app is doing more to let users know about the state and quality of a bug report.

Some Launchpad users may have noticed that we are not syncing bug watches with external trackers as we should. We have had to turn off syncing with external trackers while we work on a problem we have had with hammering bug trackers with large numbers of bug watches in Launchpad.

The Launchpad Bugs team has been doing a lot of work recently to improve our handling of bug syncing between Launchpad and external trackers. We’ve fixed several bugs. Unfortunately, we cannot re-enable syncing with external trackers until we are certain we will not hammer an external tracker.

We expect bug syncing to be down through the weekend and fixed early next week. Interested developers can follow progress at the bug linked above.

Launchpad’s 3.1.12 release has been a big release for the Launchpad Bugs team, despite it only being a two week development cycle compared to the normal four week cycle for Launchpad releases.  This meant there was really only a week of development time for the bugs team.  We’ve been anxious to really put some development effort to the plans we’ve been articulating at sprints and UDS over the last few weeks prior to the start of the 3.1.12 cycle, so we discussed in our team being very careful with our time during this short cycle so that we could end the year with a hint of the work to come over the next 2-3 months.

Better Patch Tracking

One of the things we’ll be working on over the next months is better patch tracking and reporting in Launchpad.  The first fruits of this have landed with changes to distinguish patches in comments and to list patches separately on the bug page.

Now when you attach a patch to a Launchpad bug, the patch has a new icon to distinguish it from any other attachment.

Patches are also now listed separately in the sidebar from other attachments on the bug page.

This work is part of the larger story of better patch tracking in Launchpad which will be one of three stories within the larger story of connecting Ubuntu, upstreams, and users that the bugs team will focus on in the next few months of development work.

Stopping Filebug Timeouts

Another nice change is the filebug work that Graham already posted about when he put out his call for early testing.  This changes lands with 3.1.12 and filing a bug should rarely time out now.

Showing Affected Users

Also, Martin previously blogged about our now showing the number of affected users on a bug page.  This is part of the story we’re calling Bug Q&A and also relates to our efforts to deliver a quality bug heat metric on Launchpad bugs.

More to Come From the Bugs Team

Each of these when taken on their own is not a large new feature, but it’s a nice bit of work for just a week’s worth of development.  Hopefully, this will also give Launchpad users a sense of what is to come in the next few months of development in the Launchpad Bugs application.  If you’re interested in following development on the Launchpad Bugs team, or maybe you’ve thought of contributing to the code, then you can check out the bugs team development plans on the Launchpad dev wiki.

Gavin just landed a very welcome branch to show the number of users affected by a bug on the bug page (bug 494040). You can also sort a list by the number of users affected, and doing this shows that two other popular bugs are related: provide a list of bugs affecting a user (283539) and show the number of affected users in a bug list (271332).

Needless to say, the bugs that affect the most users aren’t always the ones that should be fixed first. But it’s useful data, and more useful now that it’s easily available.

You’ll be able to use this after the release of Launchpad 3.1.12 on Wednesday the 16th December or on Edge right away.

For the last million years¹ or so I’ve been working on a cool new feature for Launchpad Bugs: an inline, AJAXified, asynchronous dupe finder.

For quite some time now people have encountered timeouts or long response times when trying to file bugs, particularly when they enter a long bug summary or the project that they’re filing the bugs on has a lot of bugs through which Launchpad has to search in order to be able to find possible duplicates. The upshot was that whenever a timeout occurred people were unable to file a bug and would have to back up and start again. Needless to say, this was frustrating for all involved.

The new inline dupefinder, which you’ll now find on the “Report a bug” page of any project in Launchpad (when viewed on edge.launchpad.net) is designed to stop this from being a problem, or at least to reduce the problem to a more manageable level and stop it from getting in peoples’ way. It does this in two ways:

1. The inline list of duplicates is much quicker to render than a full Launchpad page.
2. If the search for duplicates times out for some reason you’ll still be able to file a bug.

Here’s the catch: we need your help. Launchpad’s development cycle this month is very short due to the approaching year-end holiday period, so we need to get as much testing done on this as possible. Check out the dupe finder, see if it works for you and, most importantly, report a bug if it doesn’t.

One last thing: at the time of writing, the inline dupe finder only works for projects (like Launchpad Bugs), not for packages or project groups. We’ll hopefully be enabling it for project groups today and with a bit of luck for packages, too. We started off with projects only because it’s the simplest implementation of the concept and it gives us a good base to test from.

Thanks in advance for your help. Let’s make Launchpad awesome together!

¹ This might be an exaggeration.

If you’ve reported, commented on or subscribed to a bug in Launchpad, you’ll have seen Launchpad’s bug mail. It’s probably the easiest way to stay up to date with the bugs that interest you and there are a few things you can do to get the most out of it.

If you don’t read anything else…

Probably the best thing you can do to make bug mail useful is to ensure you only get the bug mail that interests you.

Launchpad makes the reasonable assumption that, if you report, comment on or subscribe to a bug, you’re interested in that bug. So, it’ll send you email updates when:

* someone changes the status, importance or targeting of the bug
* someone makes a comment on the bug.

If you find you’re no longer interested in a particular bug, check for an unsubscribe link in the footer of the bug mail. You can also visit your own bug page to check which individual bugs you’re subscribed to.

If you don’t see an unsubscribe link, it means that you’re not subscribed directly. Instead, you’re receiving the bug mail because either:

• you’re a member of a team that’s subscribed to the bug
• you’ve previously subscribed to receive all bug mail associated with a particular distro, project or part thereof.

So, what do you do?

You’re subscribed to all bugs associated with a distro or project

At the bottom of the bug mail is a link to the bug’s page in Launchpad, along with a short explanation as to why you’re receiving the bug mail. If you’re subscribed to all the bugs associated with Launchpad, for example, it might say:

You received this bug notification because you are subscribed to Launchpad itself

These bulk subscriptions do not show up on your bug page. Instead, you need to visit the distro, project or series’ bug page and follow the Subscribe to bug mail link, where you’ll be able to unsubscribe.

A team you’re in is subscribed to the bug

Similarly, if you’re subscribed to a bug indirectly through your membership of a team, the bug mail footer message will tell you which team. You now have two options to stop receiving the bug mail:

• leave the team
• if you’re absolutely certain your team-mates will be happy, unsubscribe the team from that bug, by following the link to the bug’s Launchpad page.

Of course, there is another way that isn’t as drastic as either of those two options: instead of unsubscribing, filter the bug mail to a dedicated folder.

Filtering bug mail

Most mail clients can filter your incoming mail based on certain elements, such as text in the subject line, certain mail headers and so on. Launchpad makes it easy to filter bug mail.

The most obvious thing you can use to filter your bug mail is the subject line: Launchpad adds the bug number to the start of each bug mails subject, such as:

[Bug 123456] Add some whatsits to the doodah

The footer, which explains the reason for your receiving the bug mail, can also be handy. Similarly, Launchpad adds an X-Launchpad-Message-Rationale: header to each bug mail, which you can use to filter the bug mail.

Matt Nuzum wrote an excellent guide to filtering Launchpad bug mail. It’s aimed at Gmail users but you can tailor it to your own mail client.

Duplicate bugs

If you’re subscribed to bug A and someone marks bug A as a duplicate of bug B, Launchpad automatically subscribes you to bug B. You can always follow the unsubscribe link in the mail footer.

Two-way bug communication

Before I go, I should mention that bug mail is not just a one-way conversation. You can report, comment on and alter bugs entirely by email. It’s quick and really easy. Take a look at our guide.

Don’t forget that if you reply to bug mail, your entire email will be published as a public bug comment on Launchpad. So, remove those phone numbers from your email signature if you don’t want them to be public!

You may have noticed that we introduced some useful new options when filing bugs. These are especially useful to anyone who files lots of bugs.

Something for everyone.

Everyone can now set tags when filing a bug. Previously, only people going via the advanced bug filing page would have the option.

One caveat: the tag field is not yet wired up with the magical tag auto-completer that you can use on the bug page itself, but that’s coming.

Something for bug supervisors.

If you’re filing a bug against a project for which you’re a bug supervisor, some additional fields appear in the new Extra options area (which is collapsed by default, but can be expanded by clicking on it). There are options to let you to set the initial status, the importance and the milestone of the bug, and also assign it directly to someone to work on.

If you have any problems with these new features, please file bugs against Launchpad Bugs, or talk to the help contact in #launchpad on freenode.

Even if you’ve been living on Earth, you could be forgiven for not knowing about the richer tag syntax in the advanced bug search (e.g. in Bugs in Ubuntu: Advanced search), frankly because it’s very new and it’s not mentioned anywhere in the UI (yet). There are two additions to the syntax that a handful of hardcore Launchpadders have been yearning after for some time.

First up, you can search for bugs with any tag, doesn’t matter which, and for bugs with no tags. To search for the presence of one or more tags, use “*” (asterisk) in the query, and to search for the complete absence of tags, use “-*” (minus asterisk).

Secondly, you can search for the absence of a specific tag. Simply prefix the tag with a minus, e.g. “-toaster”.

You can combine these new forms as well. For example, to search for bugs with no tags at all or with no crumpet tag, you could search for “-* -crumpet“, making sure the Any radio button is selected. Everybody needs crumpets!

Have fun!

If you run into any problems, please report the bug in Malone.