launchpadblog

Over the last 18 months, I’ve moved GNU Mailman development from SourceForge to Launchpad.  The reasons are varied.

Mailman was one of the first projects hosted on SourceForge ages ago.  I think our project id is a pride-inducing low 103, and we were even highlighted as its Project of the Month at one point.  Of course SF itself uses Mailman to serve its own mailing lists.  While the SF guys have always been great (including providing assistance during the migration to LP), I just became increasingly roadblocked by it.

The first major motivation for moving was Bazaar. This is of course the GPL’d distributed version control system developed by Canonical and used for code hosting on Launchpad.  Having come from decades of SCCS/RCS/CVS/SVN use, distributed version control systems in general and Bazaar in particular have been an enlightenment on the order of learning Python.  I mean, who’d have thunk a version control system could be fun?

After we moved code hosting to Bazaar on LP, evaluating the other benefits of Launchpad became easier.  Truth be told, there was (and still is) some resistance in the community to moving to LP because Mailman is a GNU project but LP is not open source.  That’s being fixed. The next service to migrate was the tracker, and thanks to the excellent assistance of my colleague Graham Binns, we were able to migrate the SF issues to LP.  For years, even before I joined Canonical, I let the Mailman tracker languish because I found it so difficult to use.  The simplicity and power of Launchpad’s tracker really shines for me here, especially with its ability to link across projects and artifacts (e.g. branches linked to bugs).

The next major service to consider is translations.  While being one of the first Python applicatons to be internationalized and translated, we really have a pretty crufty process for updating translations.  Some language champions have commit privileges, but others have to email or upload po-file diffs, or even entire po-files.  This really sucks for a number of reasons, probably most of which is that the code developers are too tightly coupled with the translators.  Our releases are held up for quite a while as we gather updates to more than two dozen languages.

Currently Mailman has an experimental Pootle service.  Despite the gallant efforts of its maintainer, I don’t think it’s working out too well, mostly because it’s not well known and not well integrated with the rest of Mailman’s processes.  Again, here’s where Launchpad integration would really shine for us, but until Launchpad is open sourced we won’t be moving translations here.

Due to some caching problems between our machines, some large translations have failed to import, generating strange errors such as:

• “String not terminated” (the most common one, at a big line number)
• “Got a truncated message!”
• “String is not quoted”
• “Invalid content u’msg'” (or other similar instances)

You’d see the error message in import failure emails. Retrying (sometimes a few times) would push the file through.

This morning we’ve disabled caching between the importing and file storing servers, and it seems to have fixed all the problems. However, the fix we used means that everyone will now get a broken URL in translation import failure emails. If the email mentions a URL like

http://mizuho.canonical.com:8000/SOME-NUMBER/filename

replace mizuho.canonical.com with launchpadlibrarian.net and the link should work.

If you still see one of the above errors on your imports, and you are sure it’s not a msgfmt syntax error (or bug #88831), please add a comment to the bug.

It’s not unusual for a project to be known by more than one name. Y’know, like Superman and Clark Kent. Or maybe something a bit more subtle, such as PostgreSQL/Postgres.

You can help people find your project in Launchpad, whatever name they know it by, thanks to project aliases.

Give it a whirl:

• https://launchpad.net/postgresql
• https://launchpad.net/postgres
• https://launchpad.net/pgsql

To request an alias for your project in Launchpad, ask us using Launchpad Answers. If the alias you’re requesting isn’t well-known, we’re more likely to give it to you if you let us know the background.

It’s Ubuntu Developer Week time again!

During this week, you can find a whole bunch of IRC sessions where members of the Ubuntu developer community introduce a topic — and take questions — that is of use to anyone wanting to get more deeply involved in Ubuntu development.

This time round, we’ve got the following Launchpad-related sessions:

• 16.00 Tuesday 20th Jan: Tom Berger talks about tracking bugs in Launchpad
• 18.00 Tuesday 20th Jan: Leonard Richardson introduces the Launchpad API
• 18.00 Friday 23rd Jan: Paul Hummer and Martin Albisetti host a session on using Bazaar and Launchpad together

Times are in UTC and you can find the sessions in #ubuntu-classroom on Freenode.

Back in November we in the Launchpad team made our contribution to the sartorial health of the free software world: the Launchpad t-shirt!

As someone with a clue about fashion might say, the understated charcoal grey of the shirt provides the perfect background to the bright colours of the Launchpad logo. Walk into any conference wearing one of these and everyone will instantly see that you’re all about the colaboration.

But enough of the shilling: it’s time to announce the winners — that’s right, plural — of our Launchpad t-shirt competition! To stand a chance of winning one of our shirts, you had to answer this question:

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

Now, this was always going to be a moving target. Each day, people join Launchpad and people register new teams. So, the competition was more about finding a good way to work out the answer.

Before I go into who won, and why, I’d like to thank everyone who entered and also tell you what the answer is right now: 10.28. Here’s how we worked it out:

1. add up all the active members of each Launchpad team
2. divide the result by the number of active Launchpad teams.

An honourable mention must go to João Miguel Neves whose answer of 11 was the closest of all the guesses.

So, our winners are:

• Mark Lee
• Markus Korn.

Congratulations! Launchpad t-shirts are on their way to you.

So, how did they do it?

Mark Lee

Mark was the first person to send us an answer using the Launchpad API:


from __future__ import division
from launchpadlib.launchpad import Launchpad, EDGE_SERVICE_ROOT

print team_members / team_len


(Mark’s entry is licensed under the GPL version 3.)

Markus Korn

Markus had a similar idea:


LPMODE=STAGING ipython -p launchpad -c "x = [len(i.members) for i in launchpad.people.findTeam(text='')]; print float(sum(x))/len(x); print len(x); print sum(x)"


To run Markus’ solution, you’ll need to install ipython, bzr branch lp:~thekorn/+junk/ipython.launchpad.profile and then copy/link it to ~/.ipython

Markus noticed something odd when he was working on his entry: the number of teams the API returned was lower than the number reported on Launchpad’s people/teams page. Turns out it’s a bug in the API: launchpadlib’s findTeam only returns teams that have an email address set.

Get your Launchpad t-shirt

You can get hold of your own Launchpad t-shirt — men‘s and women‘s — over in the Canonical shop.

Congratulations to both Mark and Markus and thanks again to everyone who entered the competition 🙂

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.