7

Exporting translations back upstream

Published by Henning Eggers January 28, 2009 in Cool new stuff, Translations

Providing translation work back upstream is now greatly simplified!

There is a lot of translation work going on in Launchpad, for Ubuntu as well as for other projects. There is also a lot of translation work going on for the projects, that is not done in Launchpad. This is especially true for many of the Ubuntu packages that have their own translation effort “upstream”.

For various reasons, translations imported from upstream projects may be altered in Launchpad. One possible scenario is that an error is detected in the upstream translation with no time to fix that upstream and import again, because the next Ubuntu release is imminent. The Ubuntu translator will then fix it in Launchpad and Ubuntu will have the corrected version. But now it is a matter of good community citizenship to provide that change back upstream.

So far, the only option here was to either communicate the changes manually or to download the whole translation file and provide that to the upstream project. Unfortunately this may not be easy to merge into the upstream translations which may have progressed in the meantime. This step is now simplified by a new feature that only exports those translation strings from Launchpad that were changed from what was originally imported from upstream. This export also includes translations of strings that were not translated at all before.

You can find information about the feature on the help page.

I really hope that this feature will find good use and that the upstream translations can profit much more from the translation work done in Launchpad. It is as easy as clicking on “export” and then forwarding the exported file to upstream.

Watch for more enhancements on the import/export front in the next releases.

0

Launchpad offline 22.00 – 22.30 UTC 28th January 2009

Published by Matthew Revell in Notifications

Today we’re releasing Launchpad 2.2.1. While we roll-out the code, Launchpad will be unavailable.

Going offline: 22.00 UTC 28th January 2009
Expected back: 22.30 UTC 28th January 2009.

See this blog for a release announcement!

(Subscribe to the ultra-low traffic launchpad-announce list to get notices like this by email.)

31

Adding a PPA’s key to Ubuntu

Published by Matthew Revell in PPA

Last month I mentioned that we were generating a unique key for each Personal Package Archive.

Well, that’s complete meaning each PPA now has its own key that’s used to sign its packages. And if you create a new PPA, Launchpad will generate a new key for it within a couple of hours.

This means that you now need to add the PPA’s key to apt before you install any of its packages. It’s really easy: all you need to do is copy the PPA’s public key and import it using System->Administration->Software Sources and then the Authentication tab.

Here’s a screencast that takes you through the steps:

(Higher quality Ogg Theora version)

Of course, you can also do it in the terminal. There’s more on the PPA help page.

Note: the PPA keys help you see that the package hasn’t been altered since Launchpad built it on behalf of the PPA owner. It does not mean that Launchpad, Ubuntu or Canonical endorse the packages. You should ensure you trust the PPA owner before you install their software.

0

Launchpad in the Ubuntu Developer Week

Published by Matthew Revell January 20, 2009 in General

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:

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

1

T-shirt competion results!

Published by Matthew Revell in General

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:

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

launchpad = Launchpad.get_token_and_login('Launchpad T-Shirt
competition', EDGE_SERVICE_ROOT, 'lp-cache')

team_len = 0
team_members = 0

for team in launchpad.people.findTeam(text=''):
   team_len += 1
   team_members += len(team.members)

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 🙂

26

How we’re open sourcing Launchpad.

Published by Karl Fogel January 16, 2009 in General

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.

3

Pidge!

Published by Matthew Revell January 15, 2009 in Projects

Pidge logoFergus Ross Ferrier tells us about his project, Pidge.

Matthew: What is the Pidge project?

Fergus: The goal is to have an open web platform — code and data — that students can use as a robust, trusted online community for sharing relevant information across their campus: events, initiatives, courses, peer education … all via their online ‘pidgeon hole’.

The only current installation — codename MyPidge.com, and a separate project on Launchpad — is at the University of Cambridge, England.

I can’t say it’s a raving success at the moment (it’s not), but there’s strong indication that this is a worthwhile goal, and we just need to plough on and improve it to the point where it gets widespread adoption.

Matthew: What parts of Launchpad do you use for Pidge?

Fergus: Mainly code hosting and bug / blueprint tracking at the moment. As soon as someone starts using it in a locale other than the UK, we’ll look at translation, and answers I’ll think about as a primary support method for users.

Matthew: Why did you choose Launchpad?

Fergus: The bits fitted together nicely. Linux, Apple and Django all benefit from the full-stack approach, and I really don’t want to waste my time chasing the ‘best’ software project management tool. I’d simply like to trust people at Canonical to work that out for me.

Matthew: What would you like to see changed in Launchpad?

Fergus: Consumption of OpenID…?

And it’d be super-cool if the UI and workflows were so well tested for non-technical people that I could actually send ordinary users to the Bugs / Blueprints / Answers areas and get them to chip in productively, without them having to work out the whole structure of the project.

Matthew: What do you particularly like about Launchpad?

Matthew: What’s next for Pidge?

Fergus: Well I need to learn a few things about motivating other students (and myself!) and keep ploughing on until it reaches critical mass here at the U of Cambridge.

And, as this is designed as a reusable package, I’d like to see someone at another student campus in the world taking up the gauntlet to set up a remote installation. Referrals, suggestions and introductions welcomed!

0

What’s new with the Launchpad web service API

Published by Leonard Richardson January 12, 2009 in API, Cool new stuff

The frequency of these posts has fallen off recently because I’ve been working on a Javascript client for the Launchpad web service, which we’ll be using to add some Ajax functionality to Launchpad. But it’s time for another one, featuring progress that’s visible to you.

First, an announcement: on Tuesday, the 20th of January, I’ll be doing an IRC chat on the Launchpad web service as part of Ubuntu Developer Week. See the schedule for details.

Newly published objects

The Bugs team has published CVEs through the web service. There’s a cves collection associated with every bug, and you can link and unlink CVEs from bugs.

The Soyuz team has published archives. You can use the web service to inspect a distribution archive or PPA, copy packages from one archive to another, and manage the permissions of who’s allowed to upload to an archive.

Merge proposals have also been published, but they’re read-only for now, so not very useful yet. But pretty soon you should be able to integrate them into an external code review tool.

Modify fields directly instead of through named operations

Consider the bug task object. Up to this point it’s had a number of read-only fields like ‘status’, ‘importance’, and ‘assignee’. These fields aren’t really read-only: you can modify them, but you have to know the secret. Each has a corresponding named operation: transitionToStatus, transitionToImportance, and transitionToAssignee. To modify ‘status’ you need to invoke transitionToStatus.

So you can’t modify a bug task’s status the way you can modify a bug’s description. This launchpadlib code works:

>>> bug.description = "A new description"
>>> bug.lp_save()

But this code doesn’t (except now, on staging):

>>> task.status = "New"
>>> task.lp_save()

You have to do this instead:

>>> task.transitionToStatus("New")

I’ve long felt that this transitionTo stuff is an internal detail you shouldn’t have to worry about, and judging from the bugs you’re filing, some of you agree. So I’ve made ‘status’, ‘importance’, and ‘assignee’ look like regular read-write fields.

The transitionTo methods are still available, so your old code will still work. In fact, the new code just calls the server-side transitionTo methods behind the scenes. The validation errors you used to get from passing a bad value into transitionToStatus will happen the same way if you set ‘status’ to a bad value.

There are other named operations that could be replaced by making the read-only field they modify into a read-write field, but I only changed those three bug task fields. I’ve talked to other Launchpad programmers about this new tool, and they’ll start using it according to their own schedules.

http_etag

Finally, there’s one part of the Javascript work that’s generally useful if you’re writing code against the web service on the level of HTTP requests rather than using launchpadlib. That’s the http_etag field now associated with entry objects such as people and bugs. It’s the same information provided in the HTTP header “ETag” when you get the entry object. So why send it again?

Well, imagine that you get a whole collection of bugtasks, and then decide you want to edit one of them. Ideally you’d use the value of “ETag” to make a conditional PUT or PATCH request, so that you wouldn’t accidentally overwrite someone else’s changes.

But you never got the ETag for that bugtask, because you got it as part of a collection. The http_etag field comes to the rescue here, allowing you to make a conditional PUT or PATCH without having to send a separate GET just to get the bugtask’s ETag.

24

Launchpod 15 – Launchpad’s going open source!

Published by Matthew Revell January 9, 2009 in Podcast

Launchpod: the Launchpad team podcast!

Host: Matthew Revell.
Theme: Obscurity by Barry Warsaw.

Launchpad will be open source on the 21st July this year! (22 June 2009 ed. note: we may push the date a bit, for testing purposes; it could be in August instead.)

Karl Fogel joined the Launchpad team recently as the Launchpad Ombudsman. Find out what that unusual job title means and hear Karl talk about the Launchpad team’s plans for going open source, our new development wiki and how we’re planning to build a community process around the newly open source Launchpad.

Download ogg vorbis file.

Podcast feed.

0

Day twelve – Loggerhead

Published by Administrator January 7, 2009 in 12 days of Launchpad

Welcome to the last of our Twelve days of Launchpad series. For our final spin, we’ll take a look at an open source project that not only forms an important part of Launchpad but that you can also install locally or on your own server: Loggerhead!

Loggerhead gives you a web interface to Bazaar branches, allowing you to:

You can use Loggerhead to view any branch in Launchpad by clicking the Source code tab on the branch’s overview page. Let’s see it in action on Drizzle’s trunk.

Drizzle's trunk in Loggerhead

Have a click around and you’ll see that Loggerhead gives you an easy way to navigate a Bazaar branch and explore its history.

Running Loggerhead locally

That’s only part of the Loggerhead story, though, because you can install it on your own machines. You get everything you see on Loggerhead through Launchpad, as well as the ability to browse through all branches on your machine — rather than one branch at a time — plus the option of a beefed-up search.

Right now, Loggerhead is packaged for Debian and also for Ubuntu (in universe for Jaunty and the ~bzr PPA for other Ubuntu versions).

Once you’ve installed the package — see our guide if you’re new to installing from PPAs — open a terminal, visit a directory where you have some Bazaar branches and enter:

$ serve-branches

Then, visit http://localhost:8080. That’s it: you can now browse around and use Loggerhead as a friendly interface to your Bazaar branches.

Get involved

If you have questions about Loggerhead — or you want to contribute — you can find the project on Launchpad and talk to the Loggerhead team using the Bazaar mailing list.

Previous Entries
Next Entries