launchpadblog

A few weeks ago, Matt announced the new Launchpad plugins for Bugzilla and Trac.

The plugins allow bidirectional communication between Launchpad and the remote bug trackers that have them installed. Obviously, we need to test the plugins – and that’s where we need your help.

If you know of any Trac or Bugzilla instances whose administrators might be interested in installing the requisite Launchpad plugin – or indeed if you run such a bug tracker yourself – you can find details on how to install the plugins and what you need to do to get Launchpad to work with your bugtracker on the Launchpad Help wiki:

• For Bugzilla, see http://help.launchpad.net/Bugs/BugzillaPlugin
• For Trac, see http://help.launchpad.net/Bugs/TracPlugin

So, what will installing the plugins do? Well, initially, installing one of the plugins will mean that:

• Launchpad will be able to import comments from upstream bugs which are being watched in Launchpad. If you register a bug watch against an upstream bug you’ll be able to read the conversation about that bug on Launchpad, including the comments that are made on the upstream bug tracker.
• Launchpad will be able to push comments to upstream bugs which are linked to a Launchpad bug, so if you add a comment on Launchpad in reply to a comment which was imported from an upstream bug tracker, the comment will automatically be added to the conversation on the upstream bug tracker, too. This means that users of both Launchpad and the upstream tracker can view the whole conversation about the bug without leaving their preferred environments.

Once we’re happy that the plugins are working correctly we can use them to add some even cooler functionality to Launchpad:

• Launchpad will be able to forward bugs to upstream bug trackers that have the plugin installed. Users of those bug trackers won’t have to check Launchpad for bugs registered against their project; they’ll be forwarded straight to the upstream tracker.
• If a bug watch is created against an upstream bug, Launchpad will tell the upstream bug tracker which Launchpad bug is watching it. This means that not only is there a link in Launchpad to the upstream bug, but there’s also a link in the upstream bug tracker to the Launchpad bug.

The Bugzilla plugin is licensed under the Mozilla Public License and the Trac plugin is licensed under GPLv2.

If you’ve got any questions, don’t hesitate to contact us by email at feedback@launchpad.net.

While in some parts they take their pay in Warcraft gold, round here we’re karma fiends!

To feed the habit, Tim in Launchpad’s Code Hosting team has provided another way of earning karma: making commits to any Bazaar branch that’s registered to a project in Launchpad.

We’re backdating the karma for commits but, as with all karma the older the action is the less it’ll count towards your karma score; really old actions don’t count at all. Also, +junk branches don’t count towards karma at all.

Now that the Launchpad web service API has entered beta, I’ll be posting an update every week about the improvements we make to it. This way you’ll always know what’s going on, and you’ll see when something you want to do becomes possible.

Web service improvements

This week I made one major change to the web service itself. There’s now a special top-level resource that’s an alias to “you” on Launchpad. This is a nice convenience when you’re writing scripts for yourself, but it’s practically essential if other people are going to be running your program.

Here’s how to get a reference to the person who’s running the script, using launchpadlib, our Python interface to the web service.

>>> me = launchpad.me
>>> print me.name
leonardr


If you’re not using launchpadlib, GET the service root at https://api.staging.launchpad.net/beta/, and you’ll see the URL to this resource as ‘me_link’. When you GET that URL you’ll be redirected to your own user account.

launchpadlib improvements

I spent most of my time working on launchpadlib. Apart from some bugfixes and performance improvements that you won’t even notice, I made three big improvements.

Introspection

Previously, to see what capabilities a launchpadlib object had, you had to check the reference documentation. (That documentation is two weeks out of date, by the way; we’ll be fixing that next week.) Now you can just call dir() on an object, and all of its Launchpad-derived attributes and methods will show up in the list. If you only want to see the Launchpad attributes or methods and not all the internal launchpadlib stuff, you can check lp_attributes or lp_operations. This code shows what you can do with a launchpadlib person object:

>>> me.lp_attributes
['self_link', 'resource_type_link', 'longitude', ... 'homepage_content']

>>> me.lp_operations
['addMember', ... 'setLocation']


Slices

The second new feature is the ability to slice Launchpad collections as though they were Python lists. Here’s some code that gets the 10 most recently filed bugs in Launchpad.

>>> recent_bugs = launchpad.bugs[:10]
>>> [bug.id for bug in recent_bugs]
[258042, 258041, 258040, 258039, 258038, 258037, 258036, 258033, 258032, 258030]


Previously, the only way to do this was to iterate over launchpad.bugs and insert a break statement when you’d had enough, which was very awkward.

Loading from bookmarks

The third new feature is the ability to bookmark launchpadlib objects and go back to them later, the way you can bookmark web pages in your browser. Here’s launchpadlib code to acquire a bug.

>>> a_bug = launchpad.bugs[251497]
>>> print a_bug.title
Make it possible to instantiate a resource from a URL


I can play around with that bug all I want within a Python session, but if I exit the Python session the bug will disappear. If I want to get the bug back later, I’ll need to find it again from scratch. Unless I store the bug’s unique ID (also known as its URL).

>>> print str(a_bug)
https://api.staging.launchpad.net/beta/bugs/251497


At this point I can write that string to a file or database. Later on, a different process might come online and load the string back into memory. That process can get the bug object back by passing the bug’s URL into launchpad.load().

>>> a_bug = launchpad.load("https://api.staging.launchpad.net/beta/bugs/251497")
>>> print a_bug.title
Make it possible to instantiate a resource from a URL


Pretty simple stuff–people have been saving URLs and passing them around to each other for over fifteen years. The advantage of our web service’s design is that it gives you the same power in a scripted environment.

Upcoming work

Next week I plan to spend most of my time on behind-the-scenes performance improvements. You won’t notice anything if you use launchpadlib. If you’re writing your own client, you’ll know what I’m talking about when I say “ETag support.”

Meanwhile, Edwin Grubbs will be working to expose Launchpad’s project registry through the web service.

See you next week!

If you’ve been wanting to integrate Launchpad into your development tools, or create scripts that read and write Launchpad’s dataset, your wait is over. We’ve released the initial version of our RESTful web service API to the beta testing team. Now you can integrate with Launchpad using our Python library or by making simple HTTP requests.

No longer will you need to screen-scrape or write scripts that pretend to be a web browser; your programs will be able to communicate directly with Launchpad. Our support for OAuth means your users can delegate a subset of their Launchpad privileges to your program or website, without handing over their Launchpad pasword.

Right now, the web service provides basic access to Launchpad’s people and bugs. We’re working now to expose more of Launchpad’s data–projects, milestones, and so on–and to improve the usability of the Python client. Once we’ve stabilized the framework, we’ll open up the web service API to everyone. In the meantime, you can try it out by joining the Launchpad Beta Testers team. Once you’re on the team, you can get started by visiting the help homepage.

Our Python library, launchpadlib, works as a “web service browser”. You can use it to navigate the web service from a Python script, the way you surf the Launchpad website from your web browser. You don’t need any special knowledge of web services to use launchpadlib; you can write natural-looking code like this:


>>> me = launchpad.people['my-username']
>>> me.display_name = 'My new display name'
>>> me.lp_save()


We’ll be improving launchpadlib and the web service simultaneously; this is just the beginning.

With the release of Launchpad 2.0, we’ve introduced a new, simpler, design and navigation.

Over the past couple of weeks, you may already have seen that we’ve made some changes to Launchpad’s web interface. For a start, there’s our fabulous new logo (designed by Eugene Tretyak) and new silver header bar.

The changes that we think are likely to have most effect on how you use Launchpad are:

• The beginning of the end of the Actions menu:we’ve started the process of removing the catch-all Actions menu. Now, many of the links you use to change information on a page are closer to the information itself.
• Page-wide application tabs: to emphasise the importance of the effect that switching between applications has on the information you’re viewing on the page, we’ve made the application tabs much more prominent.
• New sub-tabs: take a look at your person profile and you’ll see that below the main application tabs are a second row of tabs that switch between pages of different information about your activity in Launchpad. These new sub-tabs appear on many pages and should make it easier to drill down to the info you want.

If you come across a bug in the new web interface, please report it. If you have any other feedback, we’d love to hear from you.

You may have spotted, on the Launchpad front page, a new summary of what Launchpad’s all about:

“Launchpad is hosting service for open source projects that’s big on collaboration.”

One of the earliest manifestations of our approach to collaboration was Launchpad’s ability to track the status of the same bug as it affects different projects. For example, a bug discovered in the Silva CMS may actually be a bug in the Zope 3 web application framework.

Because both Silva and Zope 3 use Launchpad to track their bugs, Launchpad treats that shared bug report as a single entity with the same bug number and a shared comment history. The bug report turns into a cross-project effort to find a fix for everyone, while both Silva and Zope 3 keep track of how the bug affects their projects through separate statuses, assignees and so on.

Now, if that same bug also affects a project that tracks its bugs outside Launchpad – say, in Sourceforge or the Debian BTS – then it’s harder to share a comment history. Instead, Launchpad links to the bug report in the external tracker and imports it status. If the bug gets fixed by the other project, everyone working on it in Launchpad can see straight away.

However, we’re committed to the idea that a shared comment history in effect creates an ad-hoc, cross-project, team to fix the bug. A project’s choice of bug tracker – in so far as is possible – shouldn’t prevent them from taking part in that conversation.

That’s why we’re about to launch a beta test of two new GPL plugins that make it easier for Launchpad to interact with Bugzilla and with Trac. Once they’re released, the plugins will enable Bugzilla and Trac instances to share bug comment histories with Launchpad.

We’re on the look-out for people to help us test the plugins. If you’re interested, drop us a mail.

Launchpad is big. Really big. Almost two and a half million people have Launchpad user accounts and close to seven and a half thousand projects are registered in the directory.

Then there are the couple of hundred thousand bug reports, thousands of code branches, millions of translated strings, blueprints, user support questions, personal package archives, mailing lists and more.

One of the goals of Launchpad 2.0 is to make it easier to access that data and, with this release, we’re introducing the beta test of our new restful web API and Python library!

During the test, the API and library will provide access to the bug tracker, as well as people and teams. Within time, our aim is to make the API as comprehensive as the web interface. In the Launchpad team, we’re really excited by the idea that this gives you the tools to do things with Launchpad we haven’t even dreamt of.

We’ll be making the full announcement of the API beta test on this blog later this week. In the mean time, sign up to the Launchpad Beta Testers team!

Hey – quick update from Matthew Revell: Launchpad’s looking a bit different today! That’s because we’ve begun the roll-out of our next major version of Launchpad.

In fact, you may already have seen mention of Launchpad 2.0 in the press already, such as at The Register and Ars Technica.

There’ll be more from us next week, with a full run-down of what 2.0’s all about. Until then, I’ll hand back to Joey:

When designing the updated interface, many existing user interface bugs were taken into consideration as well as taking inspiration from some of the websites that we love to use. The interface updates are part of a larger effort to make Launchpad easier to use. The first noticeable changes deployed with our previous release, 1.2.6.

Matthew Paul Thomas, who looks after Launchpad’s UI, explained the changes:

“We realize that if you’ve been using Launchpad for a while, these changes may take a bit of getting used to. But we’re confident that the new designs will be more efficient once you’re familiar with them. We also expect they’ll be easier for people using Launchpad for the first time.

“They also pave the way for even simpler interfaces in future Launchpad releases, where you’ll be able to click on something and edit it in place.”

As Matthew said, we are working toward the ability to allow in-place editing where possible. These changes you see in Launchpad today are a step in that direction.

We will be making a few additional adjustments to the interface over the next few weeks as part of our polishing efforts.

Launchpad’s new code review system gives you a public place to discuss and vote on proposed code mergers. What’s more, you can easily access the discussion directly from both branches involved.

This month, we’ve added an email interface to make it easier to fit Launchpad-based code review into your workflow.

Aaron Bentley, who’s been working on the feature, explains:

Code review by email makes each merge proposal into a mini-mailing list. People can participate fully in code review whether they prefer to do it using web or email.

Taking part in a code review by email is very much like using the Launchpad bug tracker’s email interface.

Reply to an email from the code review and your comment is added to the discussion in Launchpad. If you want to vote by email, leave a space at the start of the line and then one of the following commands:

• vote approve
• vote disapprove
• vote abstain

So, now code review in Launchpad is as easy as any code review by email but with the added benefit of a public record of the code review in Launchpad.

You have noticed that things have changed in Launchpad’s web interface.

Now, on bugs pages, the translations pages and distribution overview pages you’ll see that many of the option you use most often are now in the body of the page, right next to the data they affect.

Let’s take a look at a bug in the OpenOffice.org package in Ubuntu as an example.

Here you can see that options such as “Mark as duplicate” and “Link a related branch” are now right in the body of the page. Matthew Paul Thomas, who looks after Launchpad’s UI, explained the changes:

“We realize that if you’ve been using Launchpad for a while, these changes may take a bit of getting used to. But we’re confident that the new designs will be more efficient once you’re familiar with them. We also expect they’ll be easier for people using Launchpad for the first time.

“They also pave the way for even simpler interfaces in future Launchpad releases, where you’ll be able to click on something and edit it in place.”

Let us know how you get on with these page designs.