launchpadblog

The Launchpad team is excited to announce the October 16th 2008 release of Launchpad 2.1.10!

There’s great news if you use Launchpad to host Bazaar branches, plus there’s the usual smaller new features and bug fixes.

Slashing branch upload times

From now on, you may notice that uploading a branch to Launchpad is significantly quicker. With this release, we’ve introduced support for Bazaar’s new stacked branches feature.

Over to Launchpad Code developer, Jono Lange, for details:

Stacked branches work just like normal branches but hold only the history that differentiates them from the project’s mainline.

So, if you upload a branch to a project that already has its trunk branch in Launchpad, you’re uploading only the differences between your work and the trunk.

Stacked branches mean that uploading a large project’s code to Launchpad can now take just a couple of minutes. To use them, you need to upgrade your branches to Bazaar format 1.6 and run Bazaar 1.7 or later.

See Jono’s blog post for more detail.

This bug affects me too

If you’ve ever come to file a bug and found that it’s already been reported, you may have wanted to let the project know that you too have been affected.

Trouble is: many projects find “me too” comments unhelpful because they don’t add much to the discussion.

Launchpad’s new “This bug affects me too” feature lets you record just that but without the guilt! Give it a go in our staging environment.

We’ll use the “me too” data in future to help projects identify hot bugs.

Also in Launchpad 2.1.10

You can find the full details of this release on its milestone page.

Getting help with Launchpad

Each weekday, members of the Launchpad team are taking turns to offer help with Launchpad. Check the #launchpad channel topic or our wiki page to see who’s on duty.

And finally…

Launchpad 2.1.11 is due on the 19th November. In the mean time, join us in #launchpad on Freenode and on the launchpad-users mailing list.

If you come across any bugs in Launchpad, please report them!

Recent scene at Launchpad HQ

There are few things more frustrating than working on something and then being held up because you can’t get the help you need. I know this all too well: my quest for world domination has long been stalled because the sonic screwdriver help-line people never answer my emails.

With Launchpad, we’re trying something new to make sure you get the help you need. Each week day there’s a named member of the Launchpad team whose job is to answer your questions, whether in #launchpad, in Launchpad Answers, on launchpad-users or to help@launchpad.net.

This means that on top of the usual cast of Launchpad types in #launchpad, for eight or so hours each day you’ll have a named contact that you can ping for help.

You can see which person’s on duty by checking the Help Rotation page on the Launchpad help wiki and also by looking at #launchpad’s channel topic.

Let us know what you think of the new help rotation and how we can improve it.

Telephone operators photograph from Seattle Municipal Archives. Creative Commons licensed.

You didn’t expect it, but here it is. “This Week in Launchpad’s Web API” returns for one more week! This week we’re pleased to announce that you can now search the bug tasks associated with a project, project group, distribution, or milestone. We know a lot of people have been waiting for this feature.

>>> launchpadlib_project = launchpad.projects['launchpadlib']
>>> me = launchpad.me
>>> my_launchpadlib_bugs = launchpadlib_project.searchTasks(assignee=me)


The interface to searchTasks is very similar to the interface to Launchpad’s advanced search form. That fact should get you started searching easily.

The other bug news is that you can now post a comment to a bug by invoking newMessage on the bug.

Release files are now exposed through the web service. This means you can now integrate release management tools into Launchpad. When you do a release of your program, the same tool that packages the release can upload the release file to Launchpad and make a Launchpad release for it.

>>> series = launchpad.projects['myproject'].series[0]
>>> release = series.addRelease(
...     version=new_item_name, code_name='sumo',
...     summary='super new beta',
...     description='The be-all end-all version for the next century.',
...     changelog='Fixes security bug. Adds external support.')
>>> release.add_file(filename="release.tgz",
...     file_content="[binary data]",
...     content_type="application/x-gzip")


Finally, we’ve changed launchpadlib so that when you upload a file, you need to set the filename you want the file to have on the server side. Previously, there was no way to set the filename.

>>> release_file = release.files[0]
>>> filehandle = release_file.open("application/x-gzip", "new-filename.tgz", "w")
>>> ...


This status report was put off until today because the edge site was frozen. This update is huge. We’ve made one change to launchpadlib, exposed a whole lot of Launchpad’s project registry, and published branches for the first time.

Since the development cycle is over, the next update will probably be in two weeks.

(more…)

Barry Warsaw, Francis Lacoste, and I gave an IRC chat about the Launchpad web service as part of Ubuntu Developer Week. There’s a transcript available in case you missed it.

The big news from last week is that we finally have the API documentation being generated whenever a new version of Launchpad is deployed. Whatever server your script is running against, the /+apidoc URL will contain the reference documentation for that version of Launchpad. launchpad.net’s documentation will change when we do an official release of Launchpad, and edge.launchpad.net’s and staging.launchpad.net’s will be updated much more often, as our changes get pushed out to those servers.

But there’s more! I also added support to launchpadlib for access to the binary files hosted by Launchpad: mugshots, bug attachments, and so on. This is everything described in the reference doc as “a file resource.” If you upgrade launchpadlib, you can now access these files with a Pythonic file object interface.

The server side of this has been in place since we launched the web service, so in theory you could have been messing with uploaded files this whole time by writing a custom-built client. But only recently did I update the hacking document that makes it easy to see how to do this.

Finally, Edwin, Brad, and I have continued working on exporting the Launchpad registry. Of note are three new hosted-file resources: a project’s brand, logo, and icon. Project groups also have more of their fields published.

This week: more things published through the registry, hopefully some progress on bugs as well.

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!

Hi,

Today I’m happy to announce two changes which appear on the Launchpad Legal page.

1. The Launchpad Logo, previously unlicensed, is now licensed as “Creative Commons Attribution-No Derivative Works 2.0 UK: England & Wales”. “No Derivative” was chosen to preserve our branding integrity.
2. The Launchpad Help wiki documentation and the Launchpad News blog, previously unlicensed, are now licensed as “Creative Commons Attribution 2.0 UK: England & Wales”.

These changes have been made in response to our users and other commercial entities inquiring if they can display/reuse/remix these items. Previously, any non-Launchpad use required explicit permission (except as permitted by fair-use).

Please visit the Launchpad Legal page for the full details and links to the Creative Commons Licenses.

Joey Stanford

As we’ve spoken about before on this blog, one of the cool things about Launchpad’s bug tracker is that it can link bugs together, regardless of whether they’re tracked in Launchpad or an external bug tracker.

This is great for Ubuntu, where people report issues against an Ubuntu package of an upstream project. Jorge Castro works on Ubuntu’s community team and wants to know how we could improve this for upstream projects.

So, if you’re from an upstream project and have an opinion on how we can improve the workflow between Launchpad and your external bug tracker, take Jorge’s survey.

Launchpod’s now up on the fantastic last.fm.

Help us look like we’re the cool kids in town by listening to Launchpod in a player that supports scrobbling 🙂

Take a look at the Launchpad team artist page.

We’re very pleased to announce the results of the Launchpad Logo Contest!
(See https://help.launchpad.net/logo)

The number and quality of submissions took all of us by surprise. We are
immensely pleased with the results and are in awe at what the community
has done. We had so many interesting designs that it was very difficult for
us to declare a single winner.

However, there was one design that we felt embodied what Launchpad is all
about. We were impressed by how it summarised so much about Launchpad and
yet remained beautifully simple.

So, we’re delighted to say that the winner is Eugene Tretyak!

You can view his design here: https://help.launchpad.net/logo/winning-entry

The center of the design represents how Launchpad makes it easy for
people to collaborate and connect with one another, while the surrounding
facets represent the different services that Launchpad provides.

Above all, it shows that all projects are themselves a gem and, when
combined with other gems, can turn into something brilliant.

Eugene is both an Ubuntu member and Kubuntu developer and will receive
an official Ubuntu Messenger Bag.

There are also two runners-up whose designs made the selection process very
challenging for us. Mariana Ravicole and Ambroise Coutand will each receive
a 25 GBP gift certificate to the Canonical Store in recognition of their
highly competitive and very popular designs.

Additionally, we would also like to give an honourable mention to Donn
Ingle for his contributions. Donn’s varied designs were a popular
favourite.

Finally, the Launchpad Team would like to thank everyone who participated
in the contest. We are humbled by the response and are deeply thankful to
all the participants.

Joey Stanford