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!

13

Launchpad 3.0 is here! New UI and more.

Published by Matthew Revell in Releases

The Launchpad team is proud to announce the release of Launchpad 3.0!

Highlights in this release include:

Let’s take a look at these, and more, in closer detail.

New user interface, with in-line editing

Visit Launchpad to see our new web interface. You can now view more information on many pages without scrolling, particularly on people and project profile pages.

And the web interface is now faster: you can update more data, including almost everything on bug report pages, without reloading the page.

Take a look at our screencast for more on the new interface:

(Ogg Theora version)

(Read our interview with Launchpad’s UI guy, Martin Albisetti)

Personal translation dashboards

Want to check if a translation needs your review? Or perhaps you want to see which projects need translation work in your language.

You can now get a quick overview of translation work that needs your attention by visiting your new translation dashboard.

(Read Danilo’s post on Launchpad Translations 3.0)

Automatically updated code diffs during code reviews

When you’re going through a code review, you’re likely to make changes to your code based on your reviewer’s comments.

Now, when you push your changes up to Launchpad in the middle of a code review, Launchpad updates the diff shown on the review page. So now it’s easier for your reviewers to see your proposed changes even as you update them.

Launchpad now using Bazaar 2.0

We’re now running Bazaar 2.0. This means that all new code imports — from git, Subersion and CVS sources — are in Bazaar’s new more efficient 2a format. We’re also starting to upgrade existing imported branches to the new format.

To use Bazaar’s new 2a repositories, you should upgrade to Bazaar 2.0.

Community contributions

Now that Launchpad’s an open source project, 3.0 also includes a number of contributions from developers outside Canonical’s Launchpad team.

Many thanks for their work and enthusiasm for Launchpad go to:

(See more detail on our contributions page)

Also in release 3.0

For full details of the bugfixes and blueprints that make up Launchpad 3.0, visit its milestone page.

If you come across a bug, please report it.

See you next time

Launchpad 3.1.10 is due on the 4th of November. See the releases calendar for more.

In the meantime, stay up to date with Launchpad news and views here on our blog.

As always, you can join us in channel #launchpad on irc.freenode.net and on the launchpad-users mailing list.

For development discussion, come to channel #launchpad-dev on irc.freenode.net or to the launchpad-dev mailing list.

4

Under the hood

Published by Matthew Revell in General

Bjorn Tillenius recently took the role of Launchpad Technical Architect. That, and the release of Launchpad 3.0, seemed like a good opportunity to learn a bit more about his new role.

Matthew: You’ve just taken a new role in the Launchpad team of Launchpad Technical Architect. That sounds like a big job: how is it going so far?

Bjorn: Yes, it’s indeed a big job. There are a lof of things that are in need of attention, so a big part of my work so far have been to talk to people, and get a list of the most pressing tasks written down. But I’ve also managed to do something concrete, like integrating our Windmill (a Javascript integration test framework) test suite into our zope.testing test runner, which we use for all our other tests.

Matthew: Is your role mostly concerned with the code of Launchpad or also the servers etc?

Bjorn: My role is mostly concerned with the code of Launchpad. My main objective is to make it easier to develop Launchpad, which includes designing and refactoring code to make it easier to use. I’m also concerned about ensuring that the quality of the code is high, and that we have good automated tests.

Matthew: What are your top three priorities for your new role?

Bjorn:

  1. Make it quicker to develop new pieces of code.
  2. Code reuse.
  3. Make sure Launchpad code is scalable.

Matthew: What challenges does being a large Python/Zope application throw up?

Bjorn: Complexity. There are a lot of sub-systems that need to interact, and it’s hard to keep track of everything in the code base. If you work on one part of the system, you might not know that another part of the system has already solved part of your problem.

Another big challenge is that Python is big on readability. It should be easy to read and understand your code. This is great, except when you get more users, and realise that the beautiful code you wrote is really slow. Producing code that is both beautiful and fast is hard, and sometimes impossible. You have to make a lot of compromises.

Matthew: What coming technologies look as though they might be interesting for Launchpad?

Bjorn: We’re currently looking into using Grok and memcached.

Grok is interesting, since it allows us to more easily replace our ZCML code with Python code. This makes it easier to both write, and to understand, since ZCML adds another language the developer has to learn, and it adds an indirection which can be hard to follow.

Memcached is interesting, since we currently render a big part of the HTML page on-the-fly, which is quite expensive. Memcached allows us to cache part of the page, so that our pages will render faster.

Matthew: How do you ensure a consistent approach to development and architecture of Launchpad with a distributed team?

Bjorn: Being in a distributed team certainly makes things harder, when it comes to making sure everyone does the same thing. I’d say our biggest asset here is the code review that we require before any code can land in the mainline. With another pair of eyes looking at the code, the chance of spotting areas of improvement increases. Of course, spotting mistakes at this point isn’t ideal, since it’s quite late in the process, the developer has already spent time writing the code. That’s why we also are pro-active, and use mailing lists and IRC to inform the developers about things they should be aware of when coding. We also aim to have a call with another developer, before the code is written, so that there are at least two people thinking about the design.

Most of these discussions are made on public mailing lists, so that all the developers can see and be part of the discussion.

Thanks Bjorn!

0

Launchpad 3.0 release 22.00 UTC 23rd September 2009

Published by Matthew Revell September 22, 2009 in Notifications

Launchpad’s web interface will be read-only for around one hour from 22.00 UTC on Wednesday the 23rd September. During that time package uploads and code hosting will be offline.

Going read-only: 22.00 UTC 23rd September 2009
Expected back: 23.00 UTC 23rd September 2009.

During this time we’ll be releasing Launchpad 3.0! Details of the release to follow!

Previous Entries
Next Entries