In-line bug tag editing and subscriptions
Published by Matthew Revell May 27, 2009 in Bug Tracking, Cool new stuff
There’s now more Ajaxy goodness on bug pages: in-line bug tag editing and also in-line subscriptions.
Both are simple actions that I always wished could happen without a page reload.
Have a look at the video I made or give it a go over on Launchpad’s staging environment without affecting real bug data.
View this video in Ogg Theora format.
Git branch imports now in public beta
Published by Matthew Revell May 26, 2009 in Code
Launchpad is all about bringing free software activity together in one place: it gives you one page to view the same bug as it is tracked in multiple places, you can hold discussions with other people using mailing lists and you can import code from around the web ready to use in a Bazaar branch.
Kiko calls it the great source code supermarket. Using Launchpad and Bazaar, you can access the code and version control history of projects who host their Bazaar branches or Subversion and CVS repositories pretty much anywhere on the net.
This month, we’ve added Git branches.
Try it out, tell us how you get on
Now Launchpad can import a project’s Git branch, using Bazaar’s bzr-git plugin, into a Bazaar branch hosted on Launchpad. We’re considering this as a public beta so we really want to know how you get on. Either post here or join us on the launchpad-users list.
There’s one significant limitation in this public beta: it won’t yet import Linux kernel branches. Jelmer, who has done much of the work on bzr-git, explains:
“As part of the Git network protocol Bazaar has to inform the Git server of the checksums of the Git revisions it already has, so the server doesn’t send it the full repository each time. To calculate these SHA1s Bazaar
has to bit-for-bit reconstruct the original Git revisions from the revisions that have been imported into Bazaar earlier.The first versions of git did not normalize file modes, and this in some situations led to file modes that can not be represented in Bazaar. This makes it impossible to recalculate the checksum of the original revision from the data in Bazaar.”
You get the Git branch’s version history and it works just like any other Bazaar branch. Launchpad then regularly pulls the latest version of the Git branch into the Bazaar branch.
For now, Launchpad will import master Git branches only. We’re looking at ways of importing non-master branches.
Request an import and let us know how you get on.
Launchpad read-only 22.00 UTC
Published by Matthew Revell in Notifications
We’re releasing Launchpad 2.2.5 today (26th May) at 22.00 UTC. While we roll-out the code, Launchpad will be read-only.
- Going read-only: 22.00 UTC 26th May 2009
- Back to normal: 23.00 UTC 26th May 2009
You may notice a couple of minutes around 22.00 where Launchpad is offline. That’s while we switch to read-only mode.
This release was planned for the 27th of May. We’re sorry for the short notice of the change in our release date.
What’s a build score, then?
Published by Matthew Revell May 8, 2009 in PPA
If you upload source packages to Launchpad — either to be built and distributed in a PPA or for Ubuntu’s primary archive — you’ve probably spotted the term “build score” and wondered what it represents.
A build score is the priority that Launchpad has assigned to a particular build job. I’ve just added a new page to the Launchpad help wiki that explains how Launchpad decides that priority but here’s the quick version.
When you upload a source package, Launchpad looks at:
- the target component
- the target pocket
- source urgency — defined by the packager
- time since upload to the queue
- whether the package is destined for a public or private PPA.
Launchpad then gives the build a score in each of those categories, adds it all up and the total is the build score you see on the build details page. The higher number, the higher the priority.
So, for example, a build destined for the security pocket gets a higher priority than a backport. However, to prevent lower priority packages from never making it to a builder, packages get an extra few points as they get older.
Get the full details in the guide over on the help wiki.
Import translations from Bazaar branches
Published by Henning Eggers April 29, 2009 in Translations
No, this is not a deja-vu. The last release brought you imports of translation templates from Bazaar branches, now you can import your actual translations too.
Enabling import of translations (usually called PO files) seems to be the logical next step since the import of translation templates (usually called POT files) is already in place.
There are a few scenarios in which this would be useful, but I think the most common is likely to be the initial import of translations when you start using Launchpad Translations for a project that already has translations. For this purpose I added the “Request Bazaar import” option right next to “Settings” on the menu bar of your project’s release series. Here you can request a single import of all translation files (templates and translations) that are in the branch. Just click on the button and wait for your files to show up in the import queue. You need to have an official branch linked to this release series in order to see this button.
If you have reasons for letting Launchpad continuously import both translation templates and actual translations from your branch you can set this up on the “Settings” page. Choose “” to initiate an initial full import of all files and subsequent imports of changed files into Launchpad Translations.
The approval of translation files after they are uploaded works just as if they were uploaded through the upload form. To be sure that they are automatically and quickly approved and imported place them in the same directory as the template file they refer to and name them after the approriate language code, e.g. es.po for Spanish translations.
I hope you can make good use of the feature. Next up will probably be exporting translations back into your branch. Doesn’t that sound cool?
Launchpad’s web service code released as standalone libraries
Published by Leonard Richardson in General
The last time I posted to this blog I was describing a sprint in Montreal, where we were working on refactoring the web service code and moving it from Launchpad to a standalone library. Several weeks of work later, we’re done. You can now create your own web service using the same techniques we use in Launchpad.
The library is lazr.restful, and there’s a companion client library called lazr.restfulclient. They’re also on PyPI (restful, restfulclient). The place to discuss these libraries is the lazr-users mailing list.
I’ll show you lazr.restful first. If you just want to use the package, and you have easy_install, try “easy_install lazr.restful“. You can also download the tarball and use “python setup.py install“ on it. Or you can get check out the source code:
$ bzr branch lp:lazr.restful mybranch $ cd mybranch $ python bootstrap $ python bin/buildout $ python bin/test
The test command starts up the web service defined in src/lazr/restful/example and puts it through its paces with simulated HTTP requests. The example web service shows how to use Python decorators to turn Zope interfaces into a web service with the same features as Launchpad’s web service. Just as an example, here’s what a normal Zope interface might look like:
class IPerson(Interface):
first_name = TextLine(title=u"First name", required=True)
last_name = TextLine(title=u"Last name", required=True)
Here’s what it would look like with lazr.restful annotations:
class IPerson(Interface):
export_as_webservice_entry(plural_name='people')
first_name = exported(TextLine(title=u"First name", required=True))
last_name = exported(TextLine(title=u"Last name", required=True))
lazr.restful will inspect that interface and know that you’re defining an ‘entry’ type resource, with each entry containing two bits of data. It’ll publish a WADL file describing that interface. Clients will be able to make GET, PUT, and PATCH requests to the ‘person’ resources to manipulate your application data.
lazr.restful provides annotations for every web service feature you see in Launchpad: entries, collections, hosted files, named operations, and so on. It even has some features that aren’t used by Launchpad yet, like the ability to make entries respond to DELETE requests.
lazr.restfulclient is the client side. We took almost all the code out of launchpadlib and made a generic client that will run against any lazr.restful service.
The same bootstrap–buildout–test cycle that worked for lazr.restful also works for lazr.restfulclient. The test command will start up the web service from lazr.restful, and manipulate it with Pythonic launchpadlib-like commands instead of fake HTTP requests. Given a ‘person’ resource like the one defined in the example above, you could run this code in lazr.restfulclient.
person_resource.first_name = "new first name" person_resource.lp_save()
Before long we’ll be removing almost all the code from launchpadlib leaving only the OAuth handling and some Launchpad-specific information. We’re also working to make it easier to use lazr.restful with standard WSGI applications, so you don’t have to know as much Zope.
Launchpad read-only from 22.00 UTC 29th April 2009
Published by Matthew Revell April 28, 2009 in Notifications
We’re releasing a new version of Launchpad on the 29th April at 22.00 UTC. While we roll-out the new code, Launchpad will remain online but will be read-only.
Going read-only: 22.00 UTC 29th April 2009
Expected return of read-write Launchpad: 23.30 UTC 29th April 2009
During this time, you can browse Launchpad and use Launchpad’s OpenID server to log into other services including the Ubuntu wiki and Landscape.
At 22.00 UTC, when we switch Launchpad into read-only mode, you may notice a short period when Launchpad is unavailable. If you do, please wait five minutes then try again.
Karma — where did mine go?
Published by Данило Шеган April 16, 2009 in General
A couple of days ago I posted that Launchpad had been assigning too much karma for certain types of translation work.
Basically, if you imported translation files — PO and POT files — into Launchpad from an Ubuntu package or a Bazaar branch then you got vastly more karma than if you simply translated directly through Launchpad’s web interface or uploaded PO files as ‘user uploads’.
Of course, that was unfair so we decided to adjust the inflated karma that Launchpad had awarded. The way Launchpad calculates karma is pretty complex, so the manual reduction we made to karma awarded for those translation imports has also affected karma given for other types of work — such as bugs, code, or blueprints — even for people who never did anything in Translations.
So, what’s going on?
Launchpad treats all its applications as equal in terms of the karma they can give out. Let’s call that the “total karma pool per application”. This means that if the total sum of all karma assigned in Blueprints to all users is X, the total karma assigned in Bugs or Translations will also be X.
However, X is determined as the largest of the actual sums of karma values all applications have. So, if Translations is handing out the most karma in Launchpad, all karma values for other applications will be scaled up to match.
There’s more in our explanation of karma calculation on the help pages.
So, what does this mean? After we fixed bug #286359 to send import notifications to Ubuntu packagers, we also started giving out translation import karma for them. An unproportionally large amount of karma was given out compared to other stuff in Translations, and that caused the total pool of Translations karma to grow, so X started growing for all applications. People noticed that their Translations karma was getting bigger and bigger, and reported bugs such as bug #337645. We also got a few comments on IRC. However, nobody noticed — or at least, they didn’t complain 🙂 — that their other karma was growing along with the growing total karma pool for Translations. Suddenly (or not that suddenly, the scaling factor increased over time), people had about 2–3 times more karma then they were supposed to.
Finally, 6 weeks after we introduced the problem, we’ve normalized translations karma so uploaders do not have an unfair advantage over actual translators. That meant that the total pool of Translations karma went down, and with it, X went down and everybody’s karma across the system went down, regardless of the application. Note that everybody’s non-Translations karma got proportionally scaled down, so relative karma scores are still the same (i.e. if you had more karma than your friend Terry a week ago, you’ve still got more karma than Terry today, unless Terry has subsequently gone on a Launchpad work rampage).
What can we do to lessen the consequences of any karma normalization in the future? We’ve got to be careful when introducing or modifying existing actions. We’ve got to normalize karma points before we work on a feature which actively gives them out. And we’ve got to better communicate changes like this.
So, what actually happened is: karma that was never meant to exist disappeared. Many parallels to the economic situation are easy to envision. Launchpad was The Karma Bank. 🙂
Launchpod 18: what’s new in 2.2.3 and more!
Published by Matthew Revell April 15, 2009 in Podcast
Launchpod: the Launchpad team podcast!
Hosts: Matthew Revell and Graham Binns.
Theme: Obscurity by Barry Warsaw.
- 01.35: Launchpad 2.2.3 — official bug tags, new bug activity log and multiple PPAs per person/team.
- 10.15: Henning Eggers talks about Launchpad Translations’ new feature that automatically imports translation template files from your project series’ default Bazaar branches.
- 17.24: Launchpad Performance Week the sequel! A quick look at some of what the Launchpad team have been working on in our second Launchpad Performance Week.
Normalizing karma for translation imports
Published by Данило Шеган April 14, 2009 in Translations
Translations karma we assign to Ubuntu package maintainers and project maintainers importing their translations through Bazaar is too big compared to what translators get when working through Launchpad. We’ll be scaling down the karma values for such imports, as part of resolving bug 337313 (see that for details). This means that some Ubuntu contributors will see their Translations karma drop significantly, but I am sure they won’t be surprised (or at least, honestly disappointed), since translators will get to retake their top positions as top translation contributors.
Note that this doesn’t affect uploads translators can do through Launchpad Translations web pages.


