Matthew Revell is the new Launchpad Product Manager
Published by Francis J. Lacoste August 26, 2011 in General
It’s my pleasure to announce that as of today, Matthew Revell is the new
Launchpad Product Manager replacing Jonathan Lange.
We were seduced by his bold vision for Launchpad along with his data-centric approach that he intends to bring to the role. He also has an already extensive experience interacting with Launchpad developers and users. If you read this blog, you probably read something written by him! Or you might have interacted with him in one of the many user-research sessions he ran. The introduction of user-research helped us release better designed feature. Building on this experience, we hope that his leadership will bring Launchpad to the next level.
Matt will communicate more about his plans for Launchpad shortly. In the
mean time, let’s give him our warmest congratulations!
Beta testers: try the new person picker
Published by Matthew Revell August 22, 2011 in Beta, Coming changes
When you want to assign a bug to someone, subscribe them to a blueprint and so on, you see Launchpad’s person picker. It’s where you search for someone or a team, get a list of possible matches and then select the right one.
Fairly recently, we’ve made a couple of improvements to the person picker, such as adding the person/team’s unique Launchpad ID after their display name, so you stand a better chance of choosing the right person.
The trouble is, how many of us know the Launchpad ID of each person or team we’re likely to deal with?
I know I think more in terms of someone’s IRC nick or the various associations they might have, rather than what they chose as their Launchpad ID.
That’s why we’re changing the person picker: soon, everyone will get a new version of the person picker that shows you what I think is a much more useful set of information in helping find the right person.
Here’s what it might look like:
If you’re in the Launchpad beta testers team you might have seen it already.
If you’ve used it, let us know what you think: does it give you the information you need? Have you come across any bugs to report?
Either email feedback@launchpad.net or comment directly on this post to help us shape the new person picker!
Users can now move bugs between projects and distros
Published by Curtis Hovey August 17, 2011 in General
Users can use the affects form on the bug page to change which project or distribution the bug affects. You can also select the affected package. Lp API users can assign a project, distribution, or package to the BugTask target property to change the affected bug target. The behaviour is similar to the way questions can be retargeted between projects and distributions. Affected series cannot be changed, though the affected series package can be.
Retargeting a bug to a distribution, package, or project
Previously, users had to mark a bug affecting a project or distribution as invalid, then add a new affected project or distribution. This cluttered the UI, caused excessive emails, and made pages slower.
Fast JSONCache updates now active for improved responsiveness
Published by Aaron Bentley August 5, 2011 in API, Code
I recently posted about Initializing page JavaScript from the JSONCache. Now I’m pleased to announce that you can also get updated copies of the IJSONRequestCache, to make it easier to update your page.
Brad Crittenden and I started work on this at the Dublin Thunderdome, and it’s finally been deployed. What this means is that for basically any page on Launchpad, you can append /++model++ to the URL, to get a fresh copy of the IJSONRequestCache. With ++model++, a change will typically require only two roundtrips; one to make a change, and one to retrieve an updated model. Future work may reduce this to a single roundtrip.
Why ++model++, not ++cache++? Cache is a really poor name for what the IJSONRequestCache is. Rather than providing fast access to whatever data has been previously retrieved, it is a complete collection of all the relevant data.
In Launchpad, the IJSonRequestCache is associated with the view, so we’re trying to rebrand it as the “view model”. This may seem strange from an MVC (Model, View Controller) perspective, but MVC can be recursive. A view may use a model to render itself.
Approve your own translation imports
Published by Matthew Revell July 29, 2011 in Translations
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
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.
