Launchpad Blog

See the number of duplicates

Published by Matthew Revell April 25, 2011 in Bug Tracking

Duplicate bug count Brian Murray has written a GreaseMonkey script to show how many duplicates a bug has.

I was looking at a bug with a large number of duplicates the other day and found my self wondering exactly how many duplicates it had. This information actually appears in the page source for the bug report however its a bit hard to read there!

I’ve hightlighted the duplicate count in the screenshot to really point out where it is.

I’ve also updated the firefox-lp-improvements PPA which contains a Firefox extension collecting all of the Launchpad Greasemonkey scripts with the new script.

Ajax comes to Blueprint

Published by Matthew Revell April 24, 2011 in General

An architectural blueprint Rejoice Blueprint users for Tim has brought the glory of Ajax to the main blueprint page.

He writes:

Now we can update the following without reloading the primary page:

title – the H1 heading

summary

whiteboard

assignee

drafter

approver

priority

implementation status

definition status

Using the new custom events that the page raises when the context object changes (using YUI magic and API PATCH requests), when you change the title of the blueprint, the document title (title bar) and the breadcrumbs also change. When the implementation status is updated, the overall status updates, and the “started by” and “completed by” are shown or hidden as appropriate.

This is work that I’ve wanted to see done for almost a year, and recent other changes I’ve done adding more widget wrappers and javascript goodness have made this possible without adding copious amounts of custom javascript.

A side-effect of these changes is that there are now more fields exported over the API for blueprints.

Photo by Will Scullin. Licence: CC BY 2.0

Updated featured projects list

Published by Matthew Revell April 23, 2011 in General

Last week I asked for suggestions of what should be on the Launchpad front-page featured project list.

Thanks for your suggestions! Based on your comments, I’ve added the following projects to the front page:

OpenStack: the open source cloud platform
Gufw: the GUI front-end for the UFW firewall configuration app
Tomdroid: the read-only Tomboy client for Android
District Health Information Software: health management software in use in many developing countries
Unity: the desktop experience

I’m also going to look at better ways of show-casing the projects of Launchpad. I’ll blog with more info soon.

5, 9, 23, 51, and other numbers

Published by Francis J. Lacoste April 22, 2011 in General

We are now two months away from our next Thunderdome. How are we doing in regards with the objectives set for that milestone? You may recall from my last post the objectives:

have no timeouts with a cut-off at 9s;
have an empty critical bugs queue;
getting a slot free on our ‘Next’ queue.

We practically achieved the first objective! Today, we lowered the hard timeout to 9s and this didn’t increase our number of daily timeouts. We don’t have zero timeouts yet. We still have a fair bunch of timeout bugs to fix. But we get on average 650 requests timing out in a day. That’s less than 0.01% of our traffic.

Critical bugs filed in the last 7 days
These remaining timeout bugs are part of our second objective. On that front, we are in a more difficult position. We have 259 critical bugs to close. That went up since last time! What went wrong? Well, we had less people working on critical bugs for once. That’s been fixed this week when the Orange squad rotated back on maintenance. We again have two full squads working on critical bugs. Second, we modified our OOPS reporting to show all timeouts happening, not only the ones occurring the most often. That resulted in about 30 new timeouts filed. (See the hight red bar at the start of the graph). Fortunately for us, the rate of new critical bugs is declining. We are at about 23 on average in the last two weeks. That’s still high and some of those are related to JS regressions escaping to production because our Windmill test infrastructure is disabled. This means that 51 is now the magic number. We need to close 51 of these critical bugs per week to reach 0 by the Thunderdome. That was the number we closed in our best week, just before the number of people working on criticals was reduced. So we’ll also need to reduce the number of new critical bugs found each week to succeed here.

Finally, on our last objective, like I already mentioned, the Orange squad switched back to maintenance. That’s because they completed the final bits of the project they were working on: Sharing translations between upstreams and Ubuntu. (Expect a blog post about it next week once everything is available to the general public.) That means that we need to complete 5 more projects to free a slot in our Next queue. That will be a stretch, but not impossible since of the two currently in progress, one should be completed in a couple of weeks and the other before the end of next month. And two of the remaining ones are much simpler than what we have worked on until now.

I’ll post again next month to see how the final stretch looks like.

Photo by Aslak Raanes. Licence: CC BY 2.0.

Adding a PPA to Ubuntu — the GUI way

Published by Matthew Revell April 21, 2011 in PPA

On Monday I posted a video showing how to add a PPA to Ubuntu using a terminal.

And here’s a video showing how to do it using Ubuntu’s Software Centre.

Automatic bug expiry working again

Published by Matthew Revell in Bug Tracking, Notifications

Back in February, Martin wrote that we’d re-enabled Launchpad’s bug expiry feature. This meant that, if a project had enabled bug expiry, Incomplete bugs that appeared to be abandoned would be automatically marked Expired after 60 days.

This worked for a while and then broke. Normally, our monitoring scripts would have have alerted us to the problem but, by an unfortunate coincidence, a separate bug meant that the alert for bug expiry was also broken.

Both bugs are now fixed and bug expiry is working again. Shortly after the fix went live, Launchpad expired roughly 2,000 bugs that would have expired anyway over the past few months.
The option to enable bug expiry for a project

From now on, Launchpad will expire bugs in the usual way. A bug is a candidate for expiry if:

it has the Incomplete status
the last update was more than 60 days ago
it is not marked as a duplicate of another bug
it has not been assigned to anyone
it is not targeted to a milestone.

If you run a project and you’d previously had bug expiry set to on, but have decided you no longer want it, follow the Configure bug tracker link on your project’s bug overview page and then de-select the Expire “Incomplete” bug reports when they become inactive check-box.

Tomdroid: Tomboy notes for Android

Published by Matthew Revell April 20, 2011 in Projects

I like to use Tomboy for just about any time I need to make a note. Shopping lists, a GTD collection bucket, notes from a phone call: Tomboy’s ideal.

Actually, up until recently I didn’t use Tomboy for shopping lists all that often. Making the list was fine but getting it to the supermarket usually meant printing it out, or something else that wasn’t quite as convenient as I’d like.

Baskets only

Then I installed Tomdroid.

Tomdroid does one thing and it does it well: it synchronises your Tomboy notes from elsewhere and lets you read them on your Android phone. You can import your notes from an SD card or, more usefully, synchronise with a TomboyWeb provider such as Ubuntu One.

Now I can tap out my shopping list on a real keyboard and carry it with me without a second thought. And, of course, all those other notes that make my life run smoothly are there with me wherever I am.

Tomdroid uses Launchpad for bug tracking, code hosting, blueprints and questions/answers.

You can download the latest version from the Android Market.

Photo by Tristram Biggs. Licence: CC BY-ND 2.0.

What you said: faster pages or more accurate bug counts

Published by Matthew Revell April 19, 2011 in Performance

Last week I asked what you’d prefer: faster loading pages that may have slightly inaccurate bug counts or slower loading pages where the bug counts were guaranteed to be accurate always.

Well, here’s the result:

85.9% of respondents wanted faster pages

85.9% of the people who responded to the question said they wanted faster pages, even if it meant that some of the bug counts might be a little inaccurate.

I asked a similar question on Facebook and 88% of the people who replied said they’d rather have faster pages.

We’re not going to do anything just yet. First, we want to do some more research. If we did implement this, though, it’s likely to affect only those projects with private bugs and, even then, show up only in side-boxes such as this:

Bug information box