launchpadblog

Recently, Benji York joined Canonical’s Launchpad team. I asked him a little about himself and his work.

Matthew: What do you do on the Launchpad team?

Benji: I work on the Foundations team. Right now I’m concentrating on the web service APIs and improving the OpenID integration.

Matthew: Can we see something that you’ve worked on?

Benji: There’s not much to see yet. Most of my changes thus far have been bug fixes or purely internal.

Matthew: Where do you work?

Benji: I work from my home in Virginia, USA.

Matthew: What can you see from your office window?

Benji: Just the shrubs that border my lawn. Once the weather cools off a bit I want to try working from the wifi-covered park/beach near my house.

Matthew: What did you do before working at Canonical?

Benji: I worked at Zope Corporation for about 6 years, most of that time as the team lead for their main product. Before that I worked in the automotive industry, mostly writing supply chain and manufacturing software.

Matthew: How did you get into free software?

Benji: I think the first piece of open source software I used to any degree was Python 1.5. Since then open source software has slowly taken over almost every niche of my computing world.

Matthew: What’s more important? Principle or pragmatism?

Benji: Pragmatism. If a thing doesn’t do what it needs to do, it’s not worth much.

However, I believe that principles are there to help us be pragmatic in a scope larger than the immediate moment. It’s not pragmatic in the long term to skimp on good design or testing just to get something out the door. Any good principal is grounded in pragmatism.

Matthew: Do you/have you contribute(d) to any free software projects?

Benji: When I was in college the console (NES, SNES, Genesis, etc.) emulation scene exploded and I had a side project that let people connect console controllers to their PC. I was approached by one of the Linux input device guys about contributing some of that code. That was my first open source contribution.

Since then I’ve made large and small contributions to dozens of open source projects. Most of those have been in the Zope ecosystem.

Lately I’ve put most of my open source hacking time into Manuel, a system for writing better tested documentation and better documented tests — it’s sort of a spiritual successor to Python’s doctest.

Matthew: Tell us something really cool about Launchpad that not enough people know about.

Benji: I’m sure most readers of this blog will know, but I didn’t know that the Launchpad and Bazaar integration is as nice as it is. Being able to branch from LP, make changes, mark the branch as fixing a particular bug, push the branch to LP, view the diffs online and then generate a merge proposal that will be automatically emailed to reviewers is very convenient.

Matthew: Is there anything in particular that you want to change in Launchpad?

Benji: I’m not familiar enough with LP yet to have strong feelings about changing it. Give it a few months and I’ll be plenty opinionated.

Recently, I’ve been working with Charline, from Canonical’s design team, to talk to Launchpad’s users about how Launchpad fits into their work and what they think of new features we’re planning.

You may have seen my requests for participants on identi.ca and Twitter 🙂

In the past, someone working on a new, or improved, feature would mock-up some ideas and post them to our development mailing list. A good discussion would result but often, not always, people who use Launchpad, rather than develop it, wouldn’t see the implementation until it was available in their browsers.

Sometimes, this meant that minor, avoidable, mistakes were made. Other times it meant that somewhat eccentric workflows made it into production and dampened the impact of what was, otherwise, a cool new feature.

Improving bug subscriptions

Graham Binns has been working on some designs for an improved way to subscribe to bug reports in Launchpad. This is something we hear about a lot and also complain about ourselves: currently, Launchpad offers too little control over how much email the bug tracker sends.

We want to get this right and so we decided that this would be one of the first feature improvements that we’d put through our new mock-up testing process.

Bug subscriptions mock-up from round 1

Here’s how it worked: Graham sent me his mock-ups and I invited six Launchpad Bugs users to come and tell me what they thought. Each person had an hour, during which I asked them to imagine they were using the mocked-up pages to complete certain tasks. I recorded what they said, while Graham made notes.

This worked better than we could have hoped. Not only did we get to see what worked, what was confusing and what was just plain stupid, we got to hear about how this feature would fit into other people’s lives, giving us an even better idea of how the feature should work.

Based on what the participants said, I wrote a list of recommendations, which Graham used to refine the mock-ups.

Ciemon Dunville during round 1

The following week, another set of people came along for round two, in which pretty much the same thing happened except we were using Graham’s new mock-ups.

The interesting thing was that, by and large, these sessions were over much quicker than those of the first round. The points of confusion from the first round had been, mostly, ironed out. We had confirmation that the first round worked and the new designs were much easier to work with.

Of course, the new design is almost certainly not perfect but it’s an awful lot better than it would have been were it not for the simple process of sitting down and asking people what they thought.

You can read the full report of both rounds on the Launchpad dev wiki.

Future testing

This is something we’ll be doing a great deal more of. Right now, I’m looking at ways that we can involve a wider range of Launchpad users (i.e. not just people who happen to be able to make it to Canonical’s London offices during work hours). That could mean working remotely, doing more of this at UDS and other events, or even visiting different places specifically to test a feature or two.

If you’re interested in participating, let me know. If you want to follow the progress of this testing, join our launchpad-dev mailing list.

Three tips from Leonard’s lightning talk in Prague about writing faster Launchpadlib API clients:

1. Use the latest launchpadlib. It gets faster from one release to the next. (The versions in the current Ubuntu release should be fine; otherwise run from the branch or the latest tarball.)

2. Profile:

    import httplib2
    httplib2.debuglevel = 1

will show each http request and response, so that you can see what’s taking time.

3. Fetch objects only once:

Don’t do this:

    if bug.person is not None:
        print bug.person.name

instead

    p = bug.person
    if p is not None:
        print p.name

In the first case, the client may fetch the Person object twice. (We may fix this in future.)

Many different types of information are stored in bug reports in Launchpad.

Some are actual defects, some are feature requests, some are general issues, and so on.  It is not uncommon on Launchpad to have a bug that deals with an issue that a developer cannot resolve.  In Launchpad, we offer a couple of bug statuses that allow a developer to close a bug report without actually doing what is requested in the report: these are Won’t Fix and Invalid.

Often, though, there may still be a discussion. Won’t Fix and Invalid are useful for the developer, and the project, to know that they don’t need to schedule time for a fix. However, they can sometimes — rightly or wrongly — be seen as an attempt to close down to discussion.

We’ve just added a new bug status to Launchpad: Opinion. Now, this is a fairly momentous occasion; we hardly ever make changes to bug statuses because they, naturally, have a great impact on how you and others use Launchpad to track bugs. However, we feel it’s important to find a way to balance a project’s need for useful work planning with the need for intelligent and open discussion.

Opinion says: there’s a difference of opinion around this bug and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed.

Like I said, adding a new bug status to Launchpad is a big deal. So, we’re treating Opinion as an experiment. We’ll watch how it is used over the next three months and then we’ll decide if the status is proving useful and effective at closing bugs while leaving the discussion open.

I’d love to hear your views on this new status: leave a comment here, join us on the launchpad-users mailing list or mail me directly.

You can now use SFTP to upload source packages to your Personal Package Archive!

If you’re already familiar with uploading to a PPA, all you need to do is ensure your dput.cf includes the following:


method = sftp
login = <your Launchpad account name>


If you’re new to PPAs, but already know how to create packages for Ubuntu, take a look at our guide.

There are all sorts of different ways in which we in Canonical’s Launchpad team keep in touch with people who use Launchpad: informal conversations on IRC, attending Ubuntu Developer Summits, formal user research and so on.

We want to hear from as many people who use Launchpad as possible. To help get there, I’ve created a survey with five questions. Tell us what you like about Launchpad, what you don’t and what sort of work you do in Launchpad:

Take the Launchpad user survey!

Steve Kowalik recently joined the Soyuz part of the Launchpad team at Canonical, so I asked him the, by now familiar, questions!

Matthew: What were you doing before you joined the Launchpad team?

Steve: I worked on the Ubuntu Mobile team for 2.5 years before switching to the Launchpad team to work on Soyuz.

Matthew: Can we see something that you’ve worked on from that time?

Steve: You sure can. The images and large parts of the integration work for Ubuntu Netbook Remix 9.04 and Ubuntu Netbook Edition 9.10 were done by me. I was also responsible for image builds for the three ARM sub-architectures for the 9.10 release.

Matthew: Where do you work?

Steve: I work from my apartment in Sydney, Australia.

Matthew: What can you see from your office window?

Steve: Another apartment block, so not the most glamorous of settings. From the other side of my apartment, I can see the local river. So it depends on the definition of office, if it’s my “office” or the balcony I work from on summer days.

Matthew: What did you do before working at Canonical?

Steve: I worked at a company in Burwood, NSW specializing in satellite communications, and worked on supporting and developing their in-house Debian-derived distribution.

Matthew: How did you get into free software?

Steve: I became interested in Linux when I was in high school, after I came across the term and researched it on the Internet. I started running it in 1999, and switched to Debian from Red Hat in 2000. I became a Debian Developer in 2001, and switched to Ubuntu in mid 2005.

Matthew: What’s more important? Principle or pragmatism?

Steve: I believe pragmatism is more important, as it allows people to use hard data to define the problem or solution space, and work within its boundaries.

Matthew: Do you/have you contribute(d) to any free software projects?

Steve: I’ve had a large number of patches and changes in Ubuntu, some in Debian, and I’ve written a Debian package checker from scratch, called Linda. I’ve been involved in free software for over ten years now.

Matthew: Tell us something really cool about Launchpad that not enough people know about.

Steve: You can now upload packages to PPAs and Ubuntu via SFTP! As an added bonus, I wrote the support for it in Launchpad.

Matthew: Is there anything in particular you plan to work on while you’re with Launchpad?

Steve: I plan on helping to make Soyuz more stable, more feature-ful and hopefully, faster.

Matthew: Okay, Kiko‘s special question! You’re at your computer, you reach for your wallet: what are you most likely to be doing?

Steve: I’m either paying a bill, or buying something online.

I am happy to report that caching rules I put in place on many pages last week are effective. I did not want to announce that pages were faster until I could see read a week of oops reports to verify that the slow pages owned by the Launchpad registry team were no longer listed as problems. I am honestly surprised that all the slow pages I changes are not listed. I expected to make a reduction in timeouts between 50% and 80%. This looks like a 100% success. I know it is not 100%, but I think this means that milestone, series, and project pages load quicker and you are seeing fewer timeouts.

Launchpad pages now have access to memcached to store fragments of pages. Parts of pages that are costly to generate are cached for minutes or hours depending on how often the data can change. In the case of distro series pages, architecture data changes every few months so the cache rules are 6 hours. Milestone pages were a challenge to cache. Active milestones cache bugs for 10 minutes, Inactive milestones cache for 3 hours. The milestone summary of statuses and assignments cache for 1 hour. If you do not know this, you may suspect there is a bug in launchpad, or wonder if you did not update a bug as you thought. We need a mechanism to expire change when data is changed.

We are now adding cache rules to other pages to improve page load times.