launchpadblog

I recently sent out an email to Launchpad users who had selected the “expire incomplete bug reports” option for their project, explaining that we would be enabling this feature again in Launchpad. Well, actually, I sent out a lot of emails. This happened partly due to poor design of the script I wrote to send the emails and partly due to my own error. I am sorry for the inconvenience this may have caused anyone. We are taking steps to ensure this sort of poorly executed mass emailing doesn’t happen again on Launchpad.

For those who haven’t heard, the rest of this blog post is meant to fill you in on the coming changes.

What is about to change?

Launchpad has always advertised that we auto-expire incomplete bugs matching certain conditions, but we haven’t done this for awhile now.  We are ready to turn this feature back on.  This means that bugs that are considered inactive will have their status automatically changed from Incomplete to Expired.  For more detail on how Launchpad determines if a bug is inactive, visit our Bug Expiry help page.

This change will take effect in about two weeks, sometime during the week of 18 October 2010.

What this means to you?

If you maintain a project in Launchpad and you want this feature, you need to ensure that the Expire “Incomplete” bug reports when they become inactive option is selected for your project on it’s Configure bug tracker page.  We have disabled it for all projects since it has been selected by default but inactive up until now. Sometime before the week of 18 October, you’ll need to re-enable this option if you want to take advantage of automatic bug expiry.

If you maintain a project in Launchpad and you do not want this feature, you do not have to do anything.

For maintainers of Ubuntu packages in Launchpad, we have left this option enabled. Getting this feature re-enabled was driven largely by requests from Ubuntu developers, so we have not changed the config options for Ubuntu packages in Launchpad.

If you have any other questions about this, feel free to leave a comment here or contact me on Launchpad.

Some bugs get reported more than once. That’s why we’ve got the dupe finder.

Some duplicate bugs slip through the dupe finder. Really common issues get quite a few dupes and someone from the relevant project usually goes through and marks them as duplicates of the master bug where the actual discussion and tracking is taking place.

There has been a really annoying bug in the way Launchpad has handled all this, though, and Deryck‘s just fixed it 🙂

Let’s say you’ve got a bug report that has a few duplicates attached to it. You then discover that, actually, there’s an older bug with a more mature discussion and that, really, that’s the master bug. Until now, before you marked your bug as a duplicate of the master, you’d first have to take all the dupes of your bug and manually make them dupes of the master.

Still with me? 🙂

For a busy bug with many dupes, some of which have their own dupes, that’s a real disincentive to clearing up the multiple duplicates and gathering everything together on the one true master bug.

Now, though, simply mark your bug as a duplicate and Launchpad will automatically transfer your bug’s dupes to the new master bug.

Simple 🙂

Some bugs attract many, many comments.

For a while now, Launchpad has displayed only the first 80 comments on any bug report, with the option of viewing the full comment history. That’s been good for speeding up page loads but not so great at offering an accurate view of the current state of discussion about the bug.

Bryce has fixed that. Now, a bug report page still shows only 80 comments, by default. However, to give a better overview of the state of discussion, it now shows the first 40 and the last 40 comments.

So, half way down the comments you’d see something like:

Here's what you see in the middle of the bug comment history

Then, at the bottom of the summarised comment history there’s this:

Comment history summary

With any luck, this should result in new bug comments that take into account the most recent discussion.

Recently, we changed the way assigning bugs works on Launchpad. It used to be that anyone could assign anyone else to a bug. This was open to abuse as you can imagine. Bug 511269 was filed about the potential problems with this, and we recently changed Launchpad so that only bug supervisors can assign a bug to someone else.

You can still assign a bug to yourself, but this does keep you from assigning someone to a bug to draw their attention to said bug. In the end, this is a good thing, though, as people should only be assigned bugs who are going to be responsible for working on them.

Now there is one issue with this change. Projects that had not established a bug supervisor for the project will find their developers can no longer assign bugs to each other. The easy fix for this is to create a bug supervisor team for your project and have the people working on your bugs assigned to this team. We do realize this might be a bit heavy weight for some projects, so we’ve opened bug 603281 about this issue.  A fix for this — only requiring bug supervisor permissions if bug supervisor is defined — should be appearing on Launchpad soon.

Many different types of information are stored in bug reports in Launchpad.

Some are actual defects, some are feature requests, some are general issues, and so on.  It is not uncommon on Launchpad to have a bug that deals with an issue that a developer cannot resolve.  In Launchpad, we offer a couple of bug statuses that allow a developer to close a bug report without actually doing what is requested in the report: these are Won’t Fix and Invalid.

Often, though, there may still be a discussion. Won’t Fix and Invalid are useful for the developer, and the project, to know that they don’t need to schedule time for a fix. However, they can sometimes — rightly or wrongly — be seen as an attempt to close down to discussion.

We’ve just added a new bug status to Launchpad: Opinion. Now, this is a fairly momentous occasion; we hardly ever make changes to bug statuses because they, naturally, have a great impact on how you and others use Launchpad to track bugs. However, we feel it’s important to find a way to balance a project’s need for useful work planning with the need for intelligent and open discussion.

Opinion says: there’s a difference of opinion around this bug and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed.

Like I said, adding a new bug status to Launchpad is a big deal. So, we’re treating Opinion as an experiment. We’ll watch how it is used over the next three months and then we’ll decide if the status is proving useful and effective at closing bugs while leaving the discussion open.

I’d love to hear your views on this new status: leave a comment here, join us on the launchpad-users mailing list or mail me directly.

When you’re new to a bug report that’s already had quite a bit of activity, it can take a few minutes to get a hang of what’s been happening.

Launchpad gives you a shortcut that lets you quickly see the history of the bug: the bug activity log.

Let’s take a look at a bug I’ve been working on recently: bug 544799. While the main bug page gives you the current description, comment history and details of status changes, you can get a concise yet comprehensive overview of the bug’s history by following the See full activity log link.

So, when you need to get up to speed on a bug report, head for the activity log.

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.

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

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.
(more…)

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.