Tag change emails make more sense
Published by Matthew Revell July 21, 2011 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.
Echoes from the Dublin Thunderdome
Published by Francis J. Lacoste July 15, 2011 in General
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.
Great fun it was, and I can’t wait for the next one in January.
Photo by Miss_Colleen. Licence: CC BY-NC-SA 2.0.
Squiggle
Published by Matthew Revell July 14, 2011 in General
Visit this URL:
Cool, eh?
Same works for https://bugs.launchpad.net/~, as well as code, translations, answers and blueprint.
Actually, it’ll work anywhere that you’d normally put /people/+me or your own Launchpad id — so long as you’re logged in.
For example: visit https://launchpad.net/~/+participation to see a list of all your team memberships.
Thanks to Martin Pool.
Photo based on an original by Michael Francis McCarthy. Licence: CC BY 2.0
Launchpad offline 08.00-09.00 UTC 14th July 2011
Published by Matthew Revell July 13, 2011 in Notifications
Launchpad will be fully offline (not read-only) for around one hour from 08.00 UTC on the 14th July 2011.
Launchpad goes offline: 08.00 UTC 14th July 2011
Launchpad expected back: 09.00 UTC 14th July 2011
We’re sorry for the very short notice of this down-time. Following this work, Launchpad’s performance will be back to normal.
How to tell who has what role
Published by Matthew Revell in General
So, you’re about to select someone in Launchpad — maybe you’re assigning a bug — and you’re not exactly sure you’ve got the right person. One way to confirm would be for Launchpad to tell you what relation that person has to the project you’re currently dealing with.
Sound like something that might help you?
If you’ve got 25 minutes today or tomorrow, you can help us choose the best way to show those affiliations. Sign up to let us know if you’re interested. There may even be an Amazon voucher in it for you 🙂
Better control of your bug mail
Published by Matthew Revell in Bug Tracking, Cool new stuff
As of recently, you have more control of what email Launchpad sends you about bugs.
Instead of bug subscriptions being all or nothing, you can now tell Launchpad exactly what bug-related events you want to hear about. And if you find you’re getting too much, or too little, detail you can change your subscription at any time.
What’s more, it’s now easier to filter the bug mail that Launchpad sends you.
Subscribing to an individual bug
Let’s take a look at a bug report about Gwibber. Over on the right-hand side is the Subscribe link as usual. Clicking on it, though, gives us three new options for when Launchpad should email you about this bug:
- a change is made to this bug or a new comment is added
- any change is made to this bug, other than a new comment being added
- this bug is fixed or re-opened.
You get to choose how much detail you want about the life of this bug, from receiving an email about everything through to Launchpad notifying you only when the bug is fixed or subsequently re-opened.
Editing a subscription to an individual bug
You can change your mind about your bug subscription. Simply click the Edit subscription link that appears once you’ve subscribed.
You get the same options, along with an additional option of unsubscribing entirely.
Subscribing to a project
You’ve been able to subscribe to all the bugs in a particular project or distribution (and milestone, series, packages within those) for a few years now. However, for anything but the quietest of projects this could bring a new intensity to the phrase “drinking from the fire hose”.
Now you can have sane subscriptions to these broader structures within Launchpad. Let’s subscribe to bugs in OpenStack to see how it works.
Clicking Subscribe to bug mail on OpenStack’s bug overview page gives allows you to:
- subscribe yourself or one of your teams
- name the subscription — this gets added to the emails that result
- choose whether you want to hear when a bug is opened or closed, or if you want to go into more detail.
So, now you have a subscription called OpenStack overview that’ll generate an email whenever a bug report is opened or closed in OpenStack.
Refining a project subscription
Let’s say you’re particularly interested in OpenStack documentation. No problem, you can keep your OpenStack overview subscription for everything else and add a more detailed subscription just for documentation bugs.
If that’s not enough, you can also filter by importance and status.
Muting bugs
If a particular bug becomes too noisy, you can mute it. No matter how you’re subscribed to that bug — even if you have several subscriptions that generate email about that particular report — once you’ve muted it, you won’t hear about that bug again.
Of course, you can unmute it any time you like.
Unsubscribe in anger
At the bottom of every bug mail that Launchpad sends you’ll now find a link to edit your subscriptions to that bug. So, no matter how how you’re subscribed to the bug you’ll find all those subscription listed on that page and have the option to edit each of them.
You can also get to that page by clicking Edit bug mail on the bug page itself.
And there’s more
To help with filtering, Launchpad now adds a new header to bug emails:
X-Launchpad-Subscription
It quotes the name you gave the subscription when you created it. For Gmail users, all bug emails also feature the subscription name in the footer of the email body.
And don’t forget that you can already opt-out of email about your own actions on bugs and Launchpad won’t send email about quickly corrected mistakes.
I know I’m going to find bug mail easier to deal with now. Congratulations to the Yellow Squad on delivering this feature!
In for the long poll
Published by Julian Edwards July 11, 2011 in Cool new stuff, General
Launchpad has quite a few background tasks that update things outside of your browser request, and the only way you know that they finished is to reload a page to see if it changes.
Updating the preview diff on a merge proposal is one example.
At our Launchpad sprint in Dublin a couple of weeks ago, we added a so-called “long poll” where the browser opens a long-running connection using XHR (a background Javascript connection) to a new piece of infrastructure called the “long poll server”
This server is something that the Landscape team originally wrote and we’ve now open-sourced it so we can use it in Launchpad. The server connects to a RabbitMQ instance and relays information back to the browser when the background task completes so that the user doesn’t need to keep reloading the page – the page will automatically update thanks to the magic of Javascript.
The proof-of-concept is done but we now need to make it work in our production environment, which means making it more reliable, configuring the deployment and add some stats collection so we can see how it behaves. We’ll start off by only letting a small subset of people use it and grow it over time until we consider it stable enough for all users.
Photo by Jay Gooby. Licence: CC BY 2.0
Launchpad read-only 08.00 UTC 13th July 2011
Published by Matthew Revell July 8, 2011 in Notifications
Launchpad’s web interface will be read-only, with aspects such as branch pushing and package uploading offline, for around 90 minutes from 08.00 UTC on the 13th July.
Starts: 08.00 UTC 13th July 2011
Ends before: 09.30 UTC 13th July 2011
This is to allow for an update to the structure of Launchpad’s database. Check our schedule of planned down-time.
