launchpadblog

Recently we announced that we’re open sourcing Launchpad, with a self-imposed deadline of 21 July 2009.  (22 June 2009 ed. note: we may push the date a bit, for testing purposes; it could be in August instead.)

Behind that announcement is a lot of activity. Obviously we’re not going to just throw the code over the wall and wish everyone good luck. The point of doing this is to bring the community that uses Launchpad.net into the development of Launchpad.net. There’s a philosophical reason for this: for a site whose primary purpose is to enable free software projects to collaborate, it’s natural that the users should be involved in improving the site itself.

But there’s a more practical reason, too.

One of my favorite metrics for judging a project’s success is to watch its bug tracker: the more bugs filed, and the faster the rate of new filings, the more successful the project is.

Those who don’t work in software sometimes express puzzlement at that metric: “What? How can more bugs be better?” But software developers know exactly what I mean: the rate of bug filing is proportional to the number of users, not to the number of actual bugs. (More precisely, it’s proportional to some combination of the number of users and their level of technical sophistication, since certain kinds of users are much more likely to file bugs than others.)

Well, I’ve been watching the Launchpad.net bug tracker for several weeks now, and judging by the bug-filing metric, Launchpad.net is very successful. Great. But what that means in practice is that we can’t resolve the majority of incoming bug reports and feature requests. The Launchpad development team at Canonical simply does not have enough surface area to handle it all. If we doubled — indeed, if we quadrupled — the size of the team, it still wouldn’t be enough. With a site like this, whose user base is large, and growing rapidly, there are really only two options:

1. triage mercilessly, and leave most things undone
2. open it up and let the users help

Clearly, answer 2 is better.

It implies some preparatory work on our part, however. We’re seeding the ground with developer documentation: this has already begun, though we’re still transferring over much of our internal documentation (remember, we have to go through everything and make sure we don’t accidentally open up any confidential business-related things — all this stuff was written by people who thought it was internal to the company at the time).

We also need to go through our dependencies and make sure we don’t have any license compatibility issues. The license on Launchpad will be the AGPLv3, but we still have to vet dependencies and work out any problems. By definition, this must happen before we release, so it’s work that Canonical must do internally.

Most importantly, we need to move our development discussion forums out into the open. Fortunately, most of Canonical’s Launchpad developers already have plenty of experence working in open source communities: they’re ready for this move, and we’re planning to do it before the code itself is opened (see the schedule), to minimize the number of simultaneous changes. We’ll also be publishing policies on how we’d like the community to work, and on how changes will be accepted back into the mainline and deployed on Launchpad.net. (The short answer is that Canonical decides, of course: we host the site, therefore we are responsible for the software that runs on it. The longer answer is that we want to make it easy for good changes to make it onto the site, and have some concrete plans for how to do that.)

In the near term, the next things you’ll see are more independent modules being opened up: code extracted from Launchpad and made into independent libraries for anyone to use (for example, Storm, LAZR.config, and LAZR.delegates).

And that’s all for now. Watch this space for more.

Hi,

Today we have updated the Launchpad Legal page [1] with the following changes:

1) The Dev wiki [2] is now called out explicitly as having a CC content license.  Previously the Dev wiki proclaimed it was licensed under CC but was not listed on our Legal page.

2) The Content License section was updated for clarity. This was a housekeeping task and does not effect any Legal changes.

3) Future notifications of legal changes will be sent only to the Launchpad Announcement list [3].  Previously they were sent to the Launchpad Users list and News blog.

Joey

[1] https://help.launchpad.net/Legal
[2] https://dev.launchpad.net/
[3] https://lists.ubuntu.com/mailman/listinfo/Launchpad-announce

Since we introduced PPAs, we’ve had a number of requests for signed packages in archives. Up until now, when installing a package from a PPA Ubuntu has warned that it is unsigned.

So, if you want to sign packages in a PPA, what do you sign them with? We dismissed two of the most obvious ideas:

• signing with the author’s own key, as that’d mean either Launchpad storing their private key or doing away with the build part of PPAs and asking authors to upload binaries
• signing with one key for all PPAs, which is a bit meaningless.

Instead, starting this week we’re generating a unique key for each archive and then signing each build made from the time of the key’s creation. As someone downloading from a PPA, you can easily check the fingerprint on its overview page in Launchpad to ensure you’re getting what you expect.

It’ll take a while to generate all the keys; check your PPA overview page to see if your key is ready yet. In the mean time, some PPAs will have keys and others will continue to generate warnings about unsigned packages.

We’ll post more details in the new year.

You can now follow Launchpad news and other updates through Twitter and identi.ca!

For news and status updates, take a look at:

• twitter.com/launchpad_net
• identi.ca/launchpad

Brad‘s also running an experiment using TwitterFeed to give us:

• twitter.com/launchpadbugs
• identi.ca/launchpadbugs

TwitterFeeds takes the Atom feed of all bug reported against the Launchpad project and turns it into a stream of microblog posts.

Putting your project’s bugs into identi.ca or Twitter

If you track your project’s bugs in Launchpad, you can also turn them into an indeti.ca or Twitter stream. Similarly, you can create a stream of your project’s code branches, latest revisions or announcements!

Here’s what you need to do:

Step 1: Create an identi.ca or Twitter account — something like yourprojectbugs.

Step 2: Visit your project’s overview page in Launchpad and copy the relevant Atom feed URL.

Step 3: Log into TwitterFeed using your OpenID.

Step 4: Give TwitterFeed the Atom feed and your identi.ca or Twitter account details.

And you’re done!

Let us know how you find our first steps in microblogging Launchpad.

Update: The instructions above now cover using TwitterFeed with laconi.ca based services, such as identi.ca. It’s also worth noting that TwitterFeed supports a maximum of five updates every 30 mins so this may not be ideal if you want to ensure you get comprehensive coverage.

Need to contact someone who’s hidden their email address in Launchpad?

No problem. Launchpad profile pages now give you a way to contact that person without having to know their email address.

Over to Barry Warsaw — who worked on the feature — for more:

You can now contact up to three other Launchpad users per day, even if those users have hidden their email addresses. The recipient’s privacy is preserved (unless they respond) and you can choose which of your valid email addresses the contact message will come from.

So now you can get in touch with all prospective new team members, bug commenters, branch owners and so on.

Try it out on your own profile page.

At our recent get-together in London, we in the Launchpad team discovered a sure-fire way to turn heads: t-shirts emblazoned with the stylish new Launchpad logo.

Naturally, we want to share this milestone in sartorial expression with everyone who loves Launchpad. So, you can now buy your own Launchpad t-shirt from the Canonical store (women’s and men’s versions available).

We’re also giving one away in our competition. To enter, answer this question correctly:

What’s the average (mean) number of people per team in Launchpad?

Send your answer and UK t-shirt size (S, M, L, XL or XXL for men, XS, S, M, L or XL for women) to feedback@launchpad.net, with the subject line “T-shirt competition”, before Friday 12th December. The Launchpad team will select the winner from the correct answers.

The Launchpad team’s decision is final and we’ll need the winner’s postal address to send the t-shirt.

Good luck 🙂

Update: As more people join and register projects in Launchpad, the correct answer may vary a little.

What do you get when you bring together a group of developers, QA engineers and other Launchpad team members? Cheesy photos, of course!

Photo: Graham Binns

We’ve come by air and by land to meet in London for a couple of weeks at what we’re calling the Launchpad EPIC. It’s a rare chance to get the full Launchpad team together for planning, training and, of course, unrepentantly bad dancing.

It also means we’re in town at the same time as the London Ubuntu 8.10 release party. If you’re planning to be there, come say “hello”.

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")
>>> ...