launchpadblog

Launchpad has a nice feature for initialising on-page JavaScript, called the JSONCache. I recommend considering it as your first choice when writing JavaScript that needs to be initialised. The one downside is that due to bug #740208, it’s not available for users who aren’t logged in. But then, users who aren’t logged in don’t need a lot of JavaScript, because they can’t write to most of Launchpad.

I found out about the JSONCache when we were working on he sourcepackage +sharing-details pages recently. This JavaScript has model objects, but I didn’t know how we should initialise them. We considered initialising them from the page HTML. We considered using the web service. But it turned out there’s already a great facility for this: the JSON cache.

If you’ve hacked on Launchpad’s HTML, you probably already know that every you can get LP.cache.context and LP.cache.me from any Launchpad page. These come for free, but with a little more work, you can get any object you need:

        cache = IJSONRequestCache(self.request)
        cache.objects.update({
            'productseries': self.context.productseries,
            'upstream_branch': self.upstream_branch,
            'product': self.product,
        })

These entries will then appear in the LP.cache with the names specified in the dict.

However, they are provided as plain JavaScript mappings, unlike the values returned by lp.client.Launchpad. You can use convert_cache to create a copy of the cache containing lp.client.Entry values. This allows you to intermix values from the lp.cache and the web service freely.

convert_cache currently lives in translations/javascript/sourcepackage_sharing_details.js, but should probably be moved into lp.client.

One extension I’d love to see would be a way to retrieve an updated copy of just the JSONRequestCache for a page. That way, we could reduce our number of round-trips, and also be confident that everything was up-to-date.

I recently came back to JavaScript, having largely ignored it for a couple of years. Development in JavaScript is much nicer than I remember. I thought I should share what I’ve learned.

The first thing I’ll mention is YUI tests. If you’re a TDD developer (and if not, why not?), YUI unit tests are the way TDD should be. The change/test cycle is very fast (to run the tests, hit “reload” in your browser). And since they’re proper unit tests, they feel like a safety net when you start to make changes.

They are a good way to test your model code and HTML changes. Other members of the Launchpad team have used them to do more integration-style testing, as well. It’s somewhat difficult to set up I/O dependent tests, but that will encourage you to make most of your code I/O-independent.

For information on how to get started with them, see: Developing with YUI.Test

When I explained how we determined what feature to work on next, I mentioned that we were looking to add a stakeholders representative for the Ubuntu project. Well, it’s now done. The Ubuntu Technical Board delegated Bryce Harrington to that position.

So if you are part of the Ubuntu community and need something from Launchpad, you can now talk to Bryce.

I’m really glad to have him on that position. Not only is he a respected member of the Ubuntu community, but he also did a 6 months rotation within the Launchpad team, so has understanding of how our project operates.

He’ll now be in a position to escalate important bugs affecting the Ubuntu community, as well as present the community’s view on what new features should be prioritized. It won’t be an easy job, since the Ubuntu project is big and varied. The people who cares about bugs are often not the same that cares about translations nor the same that cares about package publishing or the Ubuntu distribution development toolchain. And the stakeholder representative job is to help prioritize these needs to make sure that the Launchpad team works on the most important work. Plus then he’ll have to find common grounds with the other stakeholder representatives!

Thanks Bryce for stepping up to these responsibilities!

Photo by Wally Gobetz. Licence: CC BY-NC-ND 2.0.

I’ve been asked this question privately a few times already. What does it mean for a squad to rotate from feature-mode to maintenance-mode? The question arises as a number of folks noticed that some members of the squad continue working on feature-related bugs after they are on maintenance shift. That happened with the former Blue squad when they completed daily builds, with the Orange squad when they completed sharing translations, and with the  Yellow squad and better bug subscriptions. So let me clarify what that boundary means.

In a nutshell, it means that the squad starts new work from a different queue. After the switch, new work will come from the general maintenance queue. Because we do the switch aligned with the calendar week, there is always work related to the feature that is still in-process (code started but not reviewed, or landed but not deployed, etc.) That’s the work that continues after the transition. After the rotation, the squad also becomes on the hook to cater for the user support duties related to maintenance mode.

What are the trade-off related to this boundary definition? The main impact is that we get a dip in maintenance related bug fixes around the rotation. That’s because the new maintenance squad has still some members not ready to start new maintenance-related work. It could be argued that because of the interrupt nature of the maintenance responsibilities, it would take longer to finish off the work related to the feature. I’m not sure that happens in practice, but I make note to check the data…

The alternative  would be to only rotate after all the feature-related bugs are done-done. The rest of the squad could fix some lower priority bugs related to the feature or clean-up tech-debt accumulated during their rotation.  It would preserve the number of people effectively working on maintenance around the transitions.  But it would mean that it would take longer before we start the next feature. And given the poor state of our feature cycle time, it’s not a trade-off that I (and I guess our stakeholders) would be willing to make at this time. We might revisit this in the future though.

Photo by Camilia Hoel. Licence: CC BY-NC-SA 2.0.

Launchpad’s test suite takes a long time to run. Far too long to wait for when you’ve made a change. And the likelihood that you’ve broken any given test is pretty small. So you probably want to start by running the tests that were likely to break.

You can usually guess which tests to run; if you’ve changed “archive.py“, you should probably run “test_archive“. But some connections are easier to miss, so I’ve hacked up a Fault Line, a bzr plugin that uses past changes to guess which test files correlate to the files you’ve changed. You can run it like so:

bin/test -m $(bzr fault-line --module-regex)

This will look at all the files you’ve changed, look at their recent history, and see which files tended to change in the last 100 revisions where you changed the specified files. The --module-regex option causes it to output a regular expression, assuming that the test files are Python modules. Otherwise, it would just output a list of the test files it found.

Thanks to Jelmer Vernoij, this is even easier to achieve for testing bzr. You just need to run “bzr selftest --auto“.

To install Fault Line, just run:
bzr branch lp:fault-line ~/.bazaar/plugins/faultline

It currently requires bzr 2.3 or later (e.g. stock Natty bzr).

Fault line is pretty limited right now. For example, the way it guesses what’s a test file is hard-coded. But a few days ago, it wasn’t even a proof of concept. Who knows what the future holds?

We are now one month away from the Dublin Thunderdome and the stakes of the game have increased substantially since last time! At UDS, Jonathan announced he was willing to take a pie in the face if we achieved our 0 critical bugs goal. Two others joined him in the bet.

As of this writing, we have 210 critical bugs left to fix to pie Jono, Ted and Neil. (203 actually, since  7 of those are bugs escalated after the bet announcement.) Unfortunately, their face seems pretty safe :-/ If we look at the trend of the last 4 weeks, we see that we are burning down about 12 bugs per week. At this rate, we would achieve this goal in 18 weeks, so around the end of September.  3 months too late for a pie! This week, the Yellow squad is starting on maintenance, so we’ll see if they can improve on the 12 bugs a week burn-down. I mean, that number is 3 times the long-term rate which is more like 4 a week, so we are definitively improving! Both because we are better at fixing bugs, but also because the number of newly found issues is declining. You can see the combined effect of this on the burndown graph as the slope gets much sharper on the right.

It doesn’t look much better on our third objective which  is to have a free slot in the stakeholders Next queue. This week the Teal squad resumed work on the our project to improve Launchpad privacy features. They did an initial break-down of the project and they have work until the next UDS! The Red squad is finishing off derived distributions, probably before the Thunderdome. But even then, at that point we would be starting on adding customizable columns on search results. And the Next queue would still be full at 2 items. On the plus side, we won’t be over our work-in-process limit anymore 🙂

I’m looking forward to see how this all turns out in Dublin, but whatever happens, at the very least, we’ll have succeeded early on our 9s timeout objective.

Photo by David Muir. Licence: CC BY-NC-ND 2.0.

When Launchpad shows someone’s display name, it’s not always clear who it’s referring to.

With so many people registered in Launchpad, it’s not surprising that some of them share a name. However, every Launchpad id is unique. Mine’s matthew.revell and no matter how many other Matthew Revells there might be in Launchpad, I’ll always be the only one with that ID.

To help clarify who’s who, we’re going to show the ID in more places alongside the display name. Two of those places are the person picker — so you know for sure that you’re selecting the right person — and at the top of the profile page.

There was some discussion, though, as to whether people would recognise that we were showing the person’s Launchpad ID. One way to make it clearer, it was suggested, would be to place a tilde in front of the ID.

On Wednesday I set up a survey asking which of these you prefer:

And which of these you prefer:

Rather than say it straight out — i.e. do you like the tilde? — I wanted to see if people noticed it.

The majority of people who responded to the survey said they preferred the versions without the tilde.

For the person picker, 23.6% of the respondents preferred the version with the tilde and 76.4% preferred the version without.

For the profile page it was a little different and even more in favour of the version without the tilde: 18.4% preferred the version with the tilde, whereas 81.6% preferred the version without.

Thanks to everyone who took part. It’s now over the to Teal Squad to digest the results.

Photo by Fling Poo. Licence: CC BY 2.0.

My colleagues in the Teal Squad have been working on a small change that’ll make it easier to distinguish Launchpad users who have similar names.

We’ve got two quick questions in our new survey. Help us make it easier to tell who’s who in Launchpad.

The survey is open for 24 hours only, so get in before 18.00 UTC on the 26th May.

Take our short survey to help us make it easier to tell who’s who in Launchpad!

Photo by Elizabeth M. Licence CC BY 2.0.

Congratulations and virtual cupcakes to nigelb and chrisjohnston who got their first changes in to Launchpad, and to the reviewers who helped get them finished off and deployed.

jml said it so well at his recent short talk:

I’m not going to kid you, [changing Launchpad is] not easy but it’s sooo worth it, you get to help all these people and you get thunderous applause like I did earlier, and really should have gone to those five guys.

(update: fixed mysteriously-broken video start-at time.)

Jonathan (our Product Strategist) and I attended UDS-O in Budapest last week. Brad, Ian, Huw and Julian also came along for some part of it. And what great feedback we received from Ubuntu contributors! Working on a big and relatively old project like Launchpad can sometime be hard. From within, we are well aware that development is slower than it could be, that we have a lot of tech-debt and a big pile of Critical bugs, not to mention the hundreds of things that we know we could do to make Launchpad more compelling. Working distributed where you interact with users and fellow developers mostly through IRC and email, and sometime voice for “richer” communication makes it even easier to lose the perspective you get when you speak to real users face-to-face.

For me, UDS brought a nice uplifting fresh air (and that’s not a small feat when you know that this is a conference where you have sometime ~400 people in close proximity in the same room 😉 I don’t have enough fingers to count the number of people who thanked us for our performance work or for some other bug fixes we did! From their perspective, Launchpad development is going well and they want more! The performance improvements we did have been noticed! And people were thrilled by the new bug subscription work.

You can get a feel for the atmosphere by watching Jono’s 5-minutes lightning talk. The audience reaction is very much in line with the individual feedback we received.

It’s always great to know your effort are appreciated by your users. Thank to all the folks at UDS. Keep the love coming!

Photo by yixing h. Licence: CC BY-NC-ND 2.0.