8

Launchpad: The next six months

Published by Jonathan Lange October 21, 2009 in General

A couple of weeks ago, the Launchpad team leads at Canonical gathered in Millbank Tower to talk about what we’ll be doing over the next six months. We talked with each other, we talked with Martin Pool from Bazaar, we talked with people on the Ubuntu Platform team, we talked with Mark Shuttleworth, we talked a lot.

Over the week, two very important things slowly began to dawn on us. I’ll talk about one of them now, and leave the other one to hang tantalizingly in the air like some forbidden fruit that’s learned how to hover.

The first important thing we realized is that Launchpad was originally conceived as a way of helping better connect the Ubuntu operating system to the upstream projects on which it depends. We further realized that could do that much better than we are right now.

A flood of bugs

Zillions of bugs get filed against Ubuntu every day. While some of them are introduced when the Ubuntu community packages software, many are really bugs in the underlying upstream code.[citation needed] And quite often they’re already fixed in the latest upstream version — it’s just that the Ubuntu package doesn’t have the fix yet.

Yet even though Ubuntu is drowning in this sea of bugs, it can’t simply forward them upstream indiscriminately. Upstreams shouldn’t be bothered with old bugs; they only want to hear about bugs that are still in their code. And Ubuntu needs to know when such a bug has been found, both to tell users that a fix is coming and to help plan packaging updates.

Package of the day

Launchpad should be doing much more to help rescue Ubuntu from this deluge. With PPAs and source package branches, Launchpad ought to be able to make it really easy to create a packaged version of the tip of any upstream, to test against, and to file bugs and provide patches directly to that upstream. That is,
Launchpad needs to make Ubuntu Daily Builds rock.

That’s going to be our overall focus now. At the same time, we’re also aware that we need to spend time polishing what we already have. So, for this month and for UDS, we’re going to be focusing only on reducing technical debt, fixing OOPSes and cleaning up the UI.

Where to now?

The Canonical Launchpad team are going to be focused on “bridging the gap” between Ubuntu and its upstreams. We’ll focus on better, faster bug triage, on making it really easy to get upstream tip on the Ubuntu desktop and really tight translations integration between Ubuntu & its upstreams. Early next week, we’ll email out a high-level roadmap of where we want to go.

We are interested in getting real-user feedback about our solution to better integrating upstreams and Ubuntu developers. If you are an upstream or Ubuntu developer interested by that problem, please contact us.

PS. If you’ve read this far, you are probably wondering what the second Very Important Thing was. I’m afraid you’ll just have to wait.

0

New lpx project group for Launchpad extensions

Published by Matthew Revell October 16, 2009 in API

Jonathan Lange writes on his blog:

Launchpad has a pretty awesome public API, implemented using lazr.restful. I’ve written a few small scripts for it, and the Launchpad team has a few scripts that they use internally for doing admin tasks.

The Ubuntu Platform team does a heap of stuff with the Launchpad API. James Westby has been using it to make sure that there’s a branch on Launchpad for every single package in Ubuntu.

There’s all this great work, but there’s been nothing to tie the room together. I’ve seen hardly any discussion about how to write Launchpad API applications, or how to test them, or how to get launchpadlib working in GTK+. I haven’t even seen much code sharing.

So, borrowing a trick from Twisted’s tx super-project, I’ve created an ‘lpx‘ project group on Launchpad. Bring it your scripts, your applications, your huddled masses. If you want to know more about the API, look at the API help page.

Also, if you’re using the Launchpad API — directly or through the launchpadlib Python library — add some info about your app to the API Uses wiki page.

2

Launchpad’s status page

Published by Matthew Revell October 13, 2009 in Notifications

When writing about the hardware running Launchpad, or even the complexity of the codebase, I’m always tempted to start off by borrowing from Douglas Adams’ introduction to The Hitchiker’s Guide to the Galaxy: “Launchpad is big. Really big.”

With such a big system, it’s inevitable that from time to time we have to rearrange the furniture a little. Aside from our monthly code roll-out, where Launchpad goes read-only for an hour or so, we occasionally have to swap out or reconfigure hardware, as you’d expect. Up until now, we’ve used a combination of this blog and the launchpad-announce mailing list to keep you up to date on any Launchpad service-affecting issues but we haven’t had a canonical (heh) status page to which you can refer and know you’re going to get a definitive answer.

So, now we have the Launchpad status page!

It’s hosted by the excellent identi.ca so you can subscribe using your identi.ca account or to the Atom or RSS feed. We’re also automatically copying everything over to the launchpadstatus Twitter account.

What does it cover?

We’re using the identi.ca-hosted status page to announce service-affecting issues that are happening right now or that we know will happen in the following 48 hours.

Also, we’re only going to post when the main production Launchpad site or the edge environment are affected, as they’re the two environments in which you can do real work.

Longer-term planning

As the status page only covers what’s happening in the next 48 hours, it’s not so useful for longer-term planning. So, as soon as we know about any pending service-interruption, we’ll add it to the maintenance page of the Launchpad dev wiki.

Blog and email updates

We’ll still continue to post notification of down-time here on the Launchpad blog and to the launchpad-announce mailing list. However, we’ll limit those posts to planned maintenance that’s likely to affect a sizeable number of people.

For things happening right now, or that are likely to be no more than the equivalent of a minor bump in the road, we’ll post them to the identi.ca-hosted status page only.

Elsewhere on identi.ca

Don’t forget, we also have a news account on identi.ca and also Twitter.

1

Bazaar 2.0.0: interview with Martin Pool

Published by Matthew Revell October 9, 2009 in Bazaar

Bazaar logoThe Bazaar project released their version 2.0.0 this week. I spoke to Martin Pool, the project’s lead, about the release and Bazaar generally.

Matthew: Congratulations on the release of Bazaar 2.0.0! If you had to come up with a headline for this release, what would it be?

Martin: “Harder, better, stronger, faster” — we made our new 2a format the default and it’s considerably smaller and faster. Ian‘s recent benchmarks show repositories in this format are substantially smaller than for Mercurial, and roughly the same size as for Git. Of course results do vary but it does correlate, and determines how much data we have to transfer from local disk or across the network.

The other cool thing about this release is that it’s the start of a stable series of 2.0.1 releases, where we’ll be landing only bugfixes and (as much as we can manage it) no new bugs or features, no API compatibility breaks, and no format changes. We’ve heard from users that in some situations they find our monthly releases too much, so we’re now going to give them the choice of a more stable series, or to keep getting new features every month with the 2.1betas.

Matthew: In the release announcement you mention that the new repository format is “substantially smaller and faster for many operations”. What in particular should I expect to notice as a Bazaar user?

Martin: The thing I actually notice most, living on the other side of the world from the Canonical (London) data centre is that pushes and pulls from Launchpad are dramatically faster — for some operations the dominant factor is the time it takes to open an ssh connection.

Matthew: Is it easy to get the new repository format up and running for my existing branches?

Martin: Yes, basically you just need to run upgrade — but you might like to read the Upgrade Guide first.

That reminds me of something else that changed recently — Ian converted our documentation to use Sphinx, so we get nicer HTML and also native Windows help files.

Matthew: The Bazaar community has done some really interesting work on repository formats. Is this new format the culmination of that or is there more you want to do?

Martin: I think there is more we could possibly do: for instance Alexander Belchenko, a user with some machines on older Windows releases, has the mantra that “OS locks must die” – we should rely on a smaller filesystem feature set, so that Bazaar works better there. Robert Collins has been sketching out a ‘dirstate2’ format for managing the working tree, that can be still smaller and faster.

But personally before we do a new public format release, I think we need to take a hard look at the user experience of a format change, especially when you have multiple developers. It is not nearly as seamless as we’d like. I think 2a gives us a good checkpoint that will work well for a while.

Matthew: What are you most excited about in this release?

Martin: I’m just thrilled it came together for such a good release, that 2a is performing so well, and that it’s into Karmic as a foundation for future stable releases.

Matthew: What makes Bazaar stand out right now from other version control systems?

Martin: I think it’d be that the transition to it can be much easier. Bazaar can be used in either a totally distributed or a centralized way, or any point in between, and that works in very well for people used to working on CVS or Subversion, or teams where some contributors are less technical. We aim to keep the user interface simple and the documentation clear, and every important feature can now be reached through the Explorer gui or through the command line. Also, Bazaar can directly interact with projects in svn, git or hg through foreign-branch plugins, so people can gradually transition.

Matthew: What advice would you offer to a project considering switching to Bazaar from another VCS?

Martin: Don’t hesitate to talk to us on IRC or the lists about how you’re planning to use it or any questions about the transition.

Matthew: What’s your favourite Bazaar plugin?

Martin: Probably bzr-explorer and qbzr, they’re coming along very quickly as a complete graphical interface.

Matthew: What’s next for Bazaar?

Martin: For the next while we’re going to especially focus on helping Ubuntu switch to bzr-based distributed development.

Matthew: Thanks Martin!

1

Code hosting offline 10.00-10.30 UTC 9th October 2009

Published by Matthew Revell October 7, 2009 in Notifications

Launchpad’s code hosting and code browse will be offline for unexpected hardware maintenance from 10.00-10.30 UTC on Friday the 9th October 2009.

During that time you won’t be able to push to, pull from, otherwise modify or browse code that is hosted on Launchpad.

Starts: 10.00 UTC 9th October
Expected back: 10.30 UTC 9th October

0

Help us improve Launchpad’s icons

Published by Matthew Revell October 5, 2009 in General

Martin posts on his blog:

We’re trying to improve the icons we have in Launchpad so they’re more usable across different cultures and types of users, and our first step is to do some user testing on our current icons.

The Canonical User Experience team has set up a survey to gather information on how users see our icons, so if you have a few spare minutes (it’s very quick!), please take the survey and pass it on to other people, especially if they don’t use Launchpad, as they will be less biased.

Here’s the link: http://www.surveymonkey.com/s.aspx?sm=6iwthaIT4FwPCsMPa1EDEA_3d_3d

0

Code Hosting offline from 10:00-10:30 UTC, Thursday 1 Oct

Published by Karl Fogel September 29, 2009 in General, Notifications

Launchpad’s Code Hosting service (code.launchpad.net and all Bazaar access) will be offline from 10:00am-10:30am UTC, Thursday, 1 October 2009. Sorry for the short notice; we need to do some unexpected hardware maintenance.

     Going offline: 10am UTC, 1 Oct 2009
     Expected back: 10:30am UTC, 1 Oct 2009

That’s 11am London (BST), 12 noon Western Europe, 2pm Moscow, 6pm Beijing, 8pm Sydney, 3am California, 6am New York.

0

Soyuz 3.0

Published by Julian Edwards September 24, 2009 in General

The Soyuz team was very, very busy over the last year fixing lots of bugs and adding plenty of new features. These are the highlights that I’d like to mention!

New features

3.0 UI

We also did a lot of complete page redesigns for 3.0:

But the work doesn’t stop here. We’re already thinking about 4.0!

0

Launchpad Translations 3.0

Published by Данило Шеган in Translations

Launchpad 3.0 is a major milestone for Translations. Along with many small improvements across the board, here are the highlights.

Improved UI and navigation

Along with the rest of Launchpad, Translations has switched to the new and stream-lined 3.0 layout. However, that’s not all: we’ve fixed a huge number of small annoyances while doing this conversion, and we expect your experience to be much nicer.

The new Launchpad layout

One of bigger improvements has come through…

Personal dashboard

You are a reviewer in a translation team, and wonder if somebody has submitted any suggestions you can look at? Or, you’re stumped about what you could translate next?

Your personal dashboard now lists all the translations you’ve worked on in the past if they’ve got something you can help with: unreviewed suggestions, or strings that need translating.

Bazaar integration

You’ve got your code hosted in Launchpad, but you have to manually upload and download tarballs with translation files?

Not any more! With 3.0, Launchpad allows you to directly import all translations from your code branches, and to have them automatically committed to a separate or the very same branch.

Translations sharing

Your project has multiple series (eg. stable and trunk)? Translators have to go through both just to keep them up-to-date? Well, not with Launchpad.

If same strings appear in both series, translating it on one will have it automatically get translated in the other.

8

Talking about Launchpad’s new interface

Published by Matthew Revell September 23, 2009 in General

Launchpad 3.0’s most noticeable feature is a new user interface. Martin Albisetti led the development of that new interface, so I asked him how the work had gone.

Matthew: What problem were you and the rest of the Launchpad team trying to solve with this UI redesign?

Martin: When I started working on Launchpad, I was presented with the challenge of bringing the project into the 2.0 era, where everything is editable inline, nice to use, fast and slick.

Mark Shuttleworth created a new team dedicated to making sure that Canonical shipped amazing user experiences in every single project, and Launchpad has been the pioneer project.

There were long-standing issues with the UI we wanted to solve, and there where many new features being worked on, the redesign was taken to make sure that the new and old worked well together. There where also a lot of infrastructure changes that needed to be made to enable us to continue developing in an Agile way and keep quality high, while we upped the bar in the experience our users had.

It’s been a great challenge, but with a team of super-stars like Launchpad it almost felt easy.

Matthew: Would you consider using Flash or other similar technologies in the Launchpad UI?

Martin: We did. Being an open source project sponsored by an open source company with an open source culture, proprietary tools are usually the last option we consider. We use Flash to create mockup movies of what we want the interaction and experience to look like, so developers can see it over and over again while they’re making javascript magic.

With browsers supporting new open technologies every single day, it didn’t make sense for us to force our users to install proprietary software to user our service. AJAX, and especially the canvas element allow us to do whatever we want. I can’t tell you enough about how grateful us web developers are for the healthy browser competition that has spring up the the last few years.

Matthew: How do you produce and maintain the templates used for Launchpad pages?

Martin: Well, it can happen in a few different ways. A common path would be:

  1. Find out what the intention of that page is.
  2. Research how users are currently using it (it’s amazing how people use pages in unexpected ways).
  3. Create a low quality mockup of what the page could look like, something easy to change.
  4. Throw it out in the public, the more feedback you can get, the less likely you will miss out on something important.
  5. Hand it over to a developer, work with them on implementing it and solving problems you didn’t predict would come up.

Launchpad uses Zope, so our templates are Zope templates. Like any technology, it has it’s advantages and it’s limitations. Sometimes it limits us on what we can ship, but rarely significantly thanks to our incredibly creative developers.

Matthew: You introduced a system of UI reviews to the Launchpad project: how did that work? Has it been a success?

Martin: This to me has been the most significant change. We have 30 developers working at the same time delivering improvements and new features to our edge users on a daily basis, and it was hard to keep the interface consistent and clean.

UI reviews where an extension of an existing process, code reviews. Not one line of code was changed or added to the project without someone else looking at it first. So I started reviewing the UI for all changes before they landed, working together to change anything that would be inconsistent or hard to understand. This had an immediate impact. Developers shifted to thinking about UI before they started programming, had the opportunity to learn in the review process and ask questions.

We got to a stage where some people had understood this so well I started building a team of UI reviewers, people who where especially interested in user interfaces and had learned from the reviewing experience. Very quickly, more than half the UI changes where being reviewed by developers. There’s a graduation process where they can approve changes with no supervision, and I already have a few candidates close to graduation day!

A wonderful side effect of inverting the roles was that the developers improved their own work, fully knowing what was required to land a change. I feel it’s been the biggest success since I joined the company over a year ago.

Matthew: How do you teach an understanding of what makes good UI?

Martin: In the process of including more people in the UI review process (and eventually, we’re aiming at including everyone) there where many hours of conversations around changes, explaining why some things needed changing and figuring out together how to do it. These conversations slowly grew into a wiki page with tips and tricks, easy to follow and understand. All this together with experience is what I feel teaches understanding of good UI.

Matthew: Many of the UI changes have involved Ajax: what have been the biggest challenges in retrofitting the web application for Ajax and also for introducing Ajax to the team?

Martin: The first challenge was picking the right tools. The rich number of options out there made this a non-trivial task. Since Launchpad was spearheading many of the changes that will happen to the rest of the web applications in Canonical, it was an exhaustive process. In the end, we gambled on using YUI3, Yahoo’s Javascript library currently in beta but in early alpha back then. YUI2 had a great reputation, well tested with a vibrant community, and YUI3 was building a new library from the ground up with all the lessons they learned from previous versions. It was the right choice.

Testing infrastructure was also a big thing for us. We’re a quality-oriented company, so we weren’t about to get into hundreds of thousands of lines of Javascript and CSS without being able to have integration and regression tests. This seems to be an area that still needs maturing. Windmill seemed like the most reasonable choice. I hear their community has been very valuable in our adoption.

Once we had made the big decisions, all the team flew into London for two weeks of javascript training to kick off the work. It was a very fun sprint.

Retrofitting I feel was easy due to the way the code base had been developed. We had HTML fallbacks for every single page already available, so we just needed to tack on a click handler to a link and we where ready to go, allowing us to use what is commonly called “progressive enhancement”.

Matthew: How have coding standards changed as a result of the UI changes?

Martin: New processes were added to bring UI to the front, we standardized on a Javascript-specific style of coding, and “trivial” changes rarely became trivial.

Matthew: Some browsers are less well supported by the Launchpad interface when it comes to Ajax. Why is that?

Martin: YUI3 grades browsers based on how well they are supported, so we inherit those standards as a base. CSS comes into play as well, so based on our user base we adapt that list. MS Internet Explorer is usually the biggest headache for us and usually gets less support as it’s a small user base.

Matthew: Thanks Martin!

Previous Entries
Next Entries