Launchpad Blog

Approve your own translation imports

Published by Matthew Revell July 29, 2011 in Translations

A road sign in Welsh and English Good news if you run a project’s translation effort in Launchpad!

Until today, when you imported a template or translation file into Launchpad for the first time, you’d have to wait for a member of the Canonical Launchpad team to review and then approve that file before your project’s translation community could make use of it.

Now, if you’re a project maintainer, you can manage your project’s translations import queue yourself. All you need do is follow the “import queue” link on your project’s translations overview page and you’ll see something like this:

Once you’ve approved a file, and it has been imported, subsequent changes will go through Launchpad’s automatic approval process.

Take a look at our guide to importing templates for more detail.

Road sign photo by Spixey. Licence: CC BY.

Less mail for mailing list admins

Published by Robert Collins July 27, 2011 in Notifications

Many mailing lists in Launchpad are open teams – that is, anyone is welcome to join, or leave, as they choose.

Until today, every time that happened all the list admins were mailed when someone joined or left their team, even though there is no action to take : in an open team, you cannot kick someone out.

We’ve fixed this – now for open teams (and only open teams) when someone joins or leaves the team, the team admins will not be notified.

In future we will have a subscription facility for team admins that do want these emails, and at that point we will make them optional for all team types.

No more monthly 90 minute downtime

Published by Robert Collins July 26, 2011 in Coming changes

I’m thrilled to be writing this blog post just over a year after starting as Launchpad’s technical architect. During that year we have been steadily improving our ability to deploy changes to Launchpad without causing downtime (of any or all services). Our ability to do this directly impacts our ability to deliver bug fixes and new functionality – our users are very sensitive to downtime.

There has been one particularly tricky holdout though – our monthly 90 minute downtime window where we apply schema changes, do DB server maintenance and so forth.

Starting very soon we will instead have very short windows – approximately 60 seconds long – where we perform schema changes, database server failover (in order to permit DB maintenance on the master server) and so forth.

We expect to do these about 6 times a month based on our historical rate of schema patches, and we are – for now – planning on doing these at 0800 UTC consistently.

This will deliver much less total downtime – 6 minutes a month rather than 90 – at the cost of more frequent interruptions.

If you have API scripts running against Launchpad, you may want to build in a retry mechanism to deal with up to a few minutes of downtime.

We cannot remove downtime entirely for purely technical reasons: Our primary database (postgresql) blocks new readers (or writers) when a schema change is being executed, and the schema change blocks on existing readers (or writers) to complete – it needs an exclusive lock on each relation being altered.

What we can do is automate the process of disconnecting and interrupting existing database connections to let the schema change execute rapidly, and make our schema changes as minimal as possible. Previously, we shut down all the application servers (via a script, but shutting down gracefully takes time), and then ran schema changes which did data migration and so forth. In this new process we will leave the appservers running and just interrupt their connections for the time it take to apply the schema change. That, combined with moving data migration to a background job rather than doing it during the schema change, gives us the short downtimes we’re about to start doing.

More information is available in the LEP and my mailing list post about the project starting.

Automatic confirmation

Published by Matthew Revell July 21, 2011 in Bug Tracking

Confirm You report a bug. Someone clicks “This affects me too” or marks the bug as a duplicate of another bug report.

Both of those are confirmation of your bug, right?

That’s what we think and members of the Ubuntu community agree.

So, from now on, that’s what’ll happen with New Ubuntu and Launchpad project bugs.

To recap: Launchpad will mark Confirmed any Ubuntu or Launchpad bug that has the New status and affects more than one person or is marked as a dupe.

Oh, but it doesn’t count if you mark your own bug as a dupe of another bug you reported.

We’re considering rolling this out for all projects in Launchpad. If your project uses Launchpad as its bug tracker, let us know what you think.

Photo by Seth Anderson. Licence: CC-BY-SA

Tag change emails make more sense

Published by Matthew Revell in Bug Tracking

Small thing this: when you change a tag on a bug, the email notification from Launchpad describes it as removing the original tag and adding a new tag.

That makes sense but something slightly irritating was that Launchpad would order the email like this:

Tags added: qa-needstesting
Tags removed: qa-untestable

The reverse order always seemed more sensible to me: i.e. first show the tags that were removed and then show the tags that were added.

Well, I wasn’t the only one to think that way and I’m glad to say that my team-mate Huw has fixed it so that bug mails now show the tags removed before the tags added.

How the Launchpad project does code review

Published by Matthew Revell July 19, 2011 in General

Not long back, Sumana Harihareswara, who is Volunteer Development Coordinator at the Wikimedia Foundation, contacted some members of the Launchpad community to ask how we handle code review.

She’s written a summary of her research for the Wikimedia community.

It makes interesting reading for someone, such as me, who’s close to the process. If you’re interested in contributing to Launchpad, Sumana’s report is a really useful overview of how we review and deploy code.

Graham Binns talks about bug subscriptions

Published by Matthew Revell July 18, 2011 in Podcast

Last week I announced Launchpad’s new bug subscriptions system!

While we were in Dublin, I recorded a chat with Graham Binns about the changes to bug subscriptions and the work that had gone into them.

Download the Ogg Vorbis file.

Echoes from the Dublin Thunderdome

Published by Francis J. Lacoste July 15, 2011 in General

Thunderdome I can’t believe it’s been two weeks already! From June 25th to July 1st, the whole Launchpad team was gathered in Dublin for our semi-annual all-hands event. Like usual, we also invited the Bazaar team and one of our friendly sysadmin.

The theme this time around was “UI, UI, UI”. Since the January squad reorganisation, it became evident that a big stumbling block for squads working on features was UI work. Our team is still inexperienced with JavaScript and the YUI3 framework. So each squad has encountered similar problems and sometime found different solutions. We wanted to take advantage of the face-time to come to a common understanding of the best patterns to use.

In the end, it was a week of intense hacking on UI infrastructure, with part of the mornings dedicated on presentation where people shared what they learnt in the past 6 months.

Projects that were worked on during the week:

An asynchronous notification system (extracted from Landscape) which will allow us to update pages as soon as tasks complete on the backend.
We ditched our buggy Windmill-based Javascript integration tests, in favour of a yuitest-based suite. We already use yuitest for JS unit tests, but now we’ll be able to use it for integration tests where we need to make XHR requests to a live server. We’ll even be able to set server-side fixtures from within the test!
Investigate the use of selenium2 for acceptance testing. These are tests ensuring a complete workflow works and that ideally will be able to run against both the staging server as well as within tree for regression testing.
Integrating loggerhead-backed branch data on some Launchpad pages. You should soon be able to get the diff of a particular revision directly on the merge proposal page.
Infrastructure to refresh all the client-side representation of objects related to a page in one request.
Many UI bugs were fixed.

This was also the week we said farewell to old friend: Jonathan our Product Strategist and Ursula Junque who is now working as QA analyst for the Ubuntu Server team. In the end, Jono didn’t get pied as we still had a huge number of Critical bugs left open. We did rejoice in achieving our performance improvements target. Given the trend, I estimated that we have still 6 months before emptying the Critical bugs list. The new target is to reduce to a 100 for October. Let’s see if I was more realistic this time around.

And we also took the traditional team picture.

Launchpad Team Photo