0

Feature Friday: project announcements

Published by Matthew Revell April 16, 2010 in Feature Friday

Not sure you need a full blog for your project but still want to announce your news?

Launchpad gives you a no-frills way to make project announcements, complete with an Atom feed.

It’s simple to get started: visit your project overview page and click Make announcement in the right-hand column’s Announcements box. There you’ll also find a link to your project’s announcements Atom feed.

Take a look at Sikuli’s announcements as an example:

Sikuli's announcements

Any announcement you make will also show up in the universal Launchpad announcements feed.

0

Links round-up 16th April

Published by Matthew Revell in General

A few links to Launchpad related posts from the past month or so:

4

–fixes lp:1234

Published by Matthew Revell April 9, 2010 in Bug Tracking, Code, Feature Friday

As I’ve said before, Launchpad is pretty big. Getting to know everything you can to do in Launchpad can take a while.

Of course, there are the user guide, the tour and the dev wiki even has a feature check-list. It’s still easy to miss things.

So, I’m turning the fifth day of each week into Feature Friday 🙂

I’m gonna kick off with something I use a lot and that, to be honest, is more a Bazaar feature, than a Launchpad feature:

bzr commit -m "Adds email functionality to the client, thereby obeying Zawinski's law." --fixes lp:1234

Adding --fixes lp:1234 to a commit tells Bazaar that the branch contains a fix for bug 1234 tracked in Launchpad.

The next time you push the branch to Launchpad, Launchpad will create a link between the branch and bug 1234.

0

How does bug triage work for you?

Published by Matthew Revell April 7, 2010 in Bug Tracking

I want to learn more about how and why people triage bugs, whether that’s in Launchpad or another bug tracker.

So, I’m inviting people who often triage bugs to come to either London or UDS in Brussels to tell me more about their experience.

If we get two or three people somewhere other than London or Brussels, we may also be able to come to you.

All I need is around an hour of your time where, along with my colleague Charline, I’ll ask you to show me how you triage bugs. If you’re interested, or have questions about how it works, mail me: matthew DOT revell AT canonical DOT com

0

Launchpad read-only 11.00-13.00 UTC 31st March 2010

Published by Matthew Revell March 26, 2010 in Notifications

We’re releasing the latest version of Launchpad on the 31st March. While we roll-out the new code, Launchpad’s web interface will be read-only and other services, such as code hosting and PPAs, will be unavailable.

Starts: 11.00 UTC 31st March 2010
Expected back by: 13.00 UTC 31st March 2010

We’ll post details of the new release right here.

3

Launchpad’s Bug Watch system and other animals

Published by Gavin Panella March 19, 2010 in Bug Tracking

Launchpad has a feature where it periodically checks the status of remote bugs (as in, bugs recorded in another bug tracker, like bug 12720 in Django).

When someone links a bug on Launchpad with a remote bug it’s called a bug watch. All the bug watches for a bug appear in the Launchpad bug page in an area called “Remote bug watches”. Check out bug 513719 to see a bug watch for bug 12720 in Django.

If the remote bug tracker has been set as the bug tracker for a project in Launchpad, bug tasks for that project can be linked to a specific remote bug too. When the status of the remote bug changes, Launchpad changes the status of the bug task to match, and sends out email to subscribers, the same as if the status had been changed in Launchpad. See the Django bug task in bug 513719 for an example.

Going further, comments can be synchronized too, in both directions. Recent versions of Bugzilla have this capability built in, but older versions can be supported with a plugin. There’s also a plugin for Trac.

This is all very nifty stuff, but it suffers because it doesn’t work very well! Yet.
Read the rest of this entry »

1

Getting started with launchpadlib: Launchpad’s Python library

Published by Matthew Revell March 11, 2010 in API

Launchpad’s strategist, Jonathan Lange, has started a series of blog posts on getting started with Launchpad’s Python library, launchpadlib:

launchpadlib is the Python client-side library that talks to Launchpad’s own REST API. It turns out that customize scripted control of a bug-tracker-code-hosting-translation-distribution-building-cross-project-collaboration thing is actually quite handy.

Catch-up with the first two posts in the series:

And you can subscribe to Jonathan’s blog or follow blogs from both Jonathan and other members of the Launchpad community on Planet Launchpad.

1

Merge proposals: improved comment handling

Published by Matthew Revell March 4, 2010 in Code

Tim has made a couple of improvements to the way that comments are displayed on merge proposals.

The first is pretty simple but makes it far easier to see which merge proposals need attention. Up until now, if you gave your merge proposal a description it would show up as a comment. This made it harder to see which merge proposals had zero activity.

Now, your description no longer shows up as a comment. And you can edit your description in-line using the same Javascript editor as you’ll find on bug pages.

The other change affects merge proposals that supersede another merge proposal. The merge proposal page explicitly states that it supersedes a previous proposal.

Notice showing the merge proposal supersedes another

It also lists all the comments from that previous review, giving them a yellow background and a link to the superseded review so you can easily tell them apart from comments on the current review.

A comment from the superseded merge proposal

2

You can’t be too helpful: Better handling of large blobs by +filebug

Published by Graham Binns in Bug Tracking

Imagine the scene, dear reader. You’re running the latest Ubuntu pre-release, dilligently testing that everything works the way it ought. An application crashes horribly; Apport pops up to tell you that it spotted the crash – would you like to report a bug?

“Of course I would,” you cry, “I am a desktop testing hero!” And so Apport does its thing and takes you to Launchpad to file the bug report. And then Launchpad times out.

At this point, if you’re like me, you might shout a bit. You refresh and refresh with all your might but still Launchpad will only give you an error page. Finally, defeated, broken, you close your browser and shuffle off into the corner of your room, where you bury yourself under the mountain of discarded CD-Rs that contain daily ISOs of Ubuntus past and sob into your coffee.

Okay, so maybe I’ve exaggerated it a bit, but that doesn’t change the basic fact that timeouts on the +filebug page when you’re filing a bug via Apport are intensely, soul-destroyingly annoying. They’re annoying to us in the Launchpad Bugs team too, because we see them in our error reports. They’re so annoying, dear reader, that we’re moved to hyperbole when writing about them for the official Launchpad blog.

The problem with processing data supplied by Apport has always been one of scale. Originally the extra data that Apport would upload to Launchpad wouldn’t be massive, maybe hitting 10MB if the application was particularly busy. Because of this, Launchpad simply processed those data synchronously whilst loading the bug-filing form for you, so that the data you’d uploaded would be included with the bug.

Of course, that approach doesn’t scale very well, and recently we’ve been seeing the data blobs that Apport uploads hit ~100MB in size. That’s far too big for Launchpad to handle in a timely manner whilst doing all the additional work of rendering the bug filing form for you, so in those circumstances it invariably times out and you get that ever-annoying error page.

This was an interesting problem to solve, and we came up with a number of different possible solutions. One viable solution for this, which we eventually decided not to implement, involved having a separate request for processing the extra bug data and then loading the data into the filebug form with AJAX. We discarded that idea because there was always the chance that that request would time out, leaving us in an only slightly better position than we were already.

There was some discussion on the Launchpad developers mailing list about whether we could just defer loading the extra data into the bug until after it had been filed, but we quickly realised that not only could the extra data carry an initial subject for the bug, but it could also indicate that the bug should be filed as private, something which currently can’t be done via the Launchpad web UI.

The solution we chose to implement, which we’ve now rolled out to the Launchpad edge and production servers, is to have a queue of blobs waiting to be processed. We already have quite a robust job-processing system built into the Launchpad codebase, which we use for creating the diffs in merge proposals and calculating bug heat, amongst other things. Adding support for processing uploaded blobs was quite simple, since the existing blob parsing code was well documented. The blob processing jobs are picked up and run by a cron script that runs every minute or so, and the data retrieved from the blobs are stored with the original processing job as a JSON-formatted string. When you hit the +filebug page it checks to see if the relevant blob has been processed. If not, it waits until processing is complete. Once processing is complete the serialized data are loaded into the +filebug page for use later on.

The advantage to you as a user, then, is that you should never again see a timeout on the +filebug page due to the size of the blob that Apport has uploaded. With the upcoming release of Ubuntu Lucid, we’re hopeful that this will make a real difference to those people testing the pre-release versions of the distro.

0

Getting Patches Upstream

Published by Karl Fogel March 3, 2010 in Bug Tracking

bugs+patches=luv

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:

Upstream report, showing number of patches in rightmost column.
(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):

The product bugs page bugfilters portlet shows the number of bugs with patches.

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:

The patch report for a project.

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

Selecting a sort by importance from the dropdown box of sort orders.

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:

Patch tasks can be sorted by importance.

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

Hovering over a patching displays a popup of information about that patch.

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:

Patch report for Ubuntu distro.

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

Patch report for a source package, about to click on the single patch.

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:

A patch file.

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:

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

Previous Entries
Next Entries