6

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?

4

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.

0

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.

5

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. 🙂

0

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.

Download ogg vorbis file.

Podcast feed.

1

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.

1

Updating the Personal Package Archive docs

Published by Matthew Revell April 9, 2009 in PPA

Recently I spent a day with Julian Edwards, one of the developers working on Launchpad’s Personal Package Archives feature.

We wanted to come up with a plan for improving the help materials we have for PPAs, including:

Right now, our PPA help guide is one long and somewhat unwieldy wiki page. Over the next couple of months, I’m going to break it down into smaller guides each based around one particular task, such as creating the source package and uploading the package, including how to deal with errors.

Up until now, we haven’t included any help on actually creating a Debian-style package ready for uploading to a PPA. One of the reasons for that was that there’s a wealth of packaging material and support already available in the Ubuntu community and more widely. However, one of the new guides I’m going to create will look at basic packaging, tailored specifically to the needs of PPAs.

If you use PPAs, I’d love your input on this work. Either mail me directly, leave a comment here or visit the bug report and blueprints I’ve created:

1

Meet Gavin Panella

Published by Matthew Revell April 7, 2009 in Meet the devs

We’re back on the Meet the devs trail and this time we’re heading for Launchpad’s most easterly UK-based developer! Let’s meet Gavin Panella.

Matthew: What do you do on the Launchpad team?

Gavin: I work on the Bugs team, adding useful new features and improving existing features in the bug tracker.

Matthew: Can we see something in Launchpad that you’ve worked on?

Gavin: I’ve been working with Graham and Björn on the bug activity log recently, which also included a lot of behind-the-scenes work to sort out bug notification emails. We have a long term goal to drive notifications from the activity log, but until recently the code was too fragmented to even contemplate that. There are two obvious changes that a Launchpad user will notice from our work so far: a far more
detailed bug activity log, and the interleaving of bug activity with comments on each bug page.

Matthew: Where do you work?

Gavin: In Norwich, UK, about a 5 minute walk from from the centre. I like it here, but it’s a little too remote; there is an airport, Norwich International, but it only seems to fly to Schipol, Alicante, and the rigs.

Matthew: What can you see from your office window?

Gavin: Another house and a car park. Not picturesque at all. But of course I’m always looking at my monitor, working on Launchpad 🙂

Matthew: What did you do before working at Canonical?

Gavin: I was self-employed in Luxembourg for a few years, doing consulting with FOSS, and worked (very indirectly) for Sir Chunky “Beard” Sweater before that at Virgin Money, working on database and web apps, and some system administration.

Matthew: How did you get into free software?

Gavin: I bought my first PC when I started uni, and spent half of the first term reinstalling Windows again and again, the excitement of which faded rapidly. Someone gave me a CDR of Red Hat, 4.2 I think, which was the first I’d heard of an alternative to DOS and Windows for PCs. Unfortunately the CD was broken, but I asked around and eventually someone (thank you, David Mansell!) took pity and helped me get Debian running.

Matthew: What’s more important? Principle or pragmatism?

Gavin: In the past I tended to get incredibly hot under the collar about trying to do things The Right Way, but working on the Launchpad team has helped me learn to be more pragmatic.

But it’s not really either/or. Principles help being pragmatic work long-term, and actually doing things helps inform your principles.

Matthew: Do you/have you contribute(d) to any free software projects?

Gavin: Not many, and not much; children take up most of my non-work time. I have contributed a little to Bazaar, and I’ve published some of my own projects in the past. Most recently I’ve contributed stuff to galleryuploader, python-macports, and storm on Launchpad.

Matthew: Tell us something really cool about Launchpad that not enough people know about.

Gavin: The API. Early adopters are using it now, but when it gets out of beta I think it will be huge, but in ways I can’t imagine yet. That’s the coolest thing; that users can get creative with Launchpad.

Matthew: Your son is named Marlow. Have you made in any Faustian pacts in your time?

Gavin: Three or four; good looks, wit, and intelligence, obviously. However, when it’s discovered that my soul is mortgaged out to multiple lenders, there will be hell to pay.

Matthew: Okay, Kiko‘s special question! You’re at your computer, you reach for your wallet: what are you most likely to be doing?

Gavin: Lending my credit card to my wife. Yep.

Matthew: Thanks Gavin!

1

Launchpad 2.2.3: multiple PPAs and translation imports from Bazaar

Published by Matthew Revell April 2, 2009 in Releases

The Launchpad team is proud to announce the release of Launchpad 2.2.3!

Here are the highlights of what’s new in this release:

Read on for more!

Additional Personal Package Archives

You can now create multiple PPAs both for yourself and your teams.

This is ideal if you’re publishing different versions of the same application to different audiences. For example: you may have one archive for alpha versions and another that’s used by your beta testers.

Visit your profile page — or that of one of your teams — to add more PPAs.

See Julian’s blog post for further details.

Translation template imports from Bazaar branches

Host your project’s code using Launchpad and Bazaar? Also translate your software using Launchpad?

Launchpad can now automatically find and import your translation templates from your project’s Bazaar branches.

Once you’ve activated automatic imports, Launchpad will monitor the official branch for each of your series and pull in any new template versions that you commit.

Read Henning’s blog post to get the full story.

Also new in this release

There’s more to Launchpad 2.2.3, including:

For full details of the bugs and blueprints that make up Launchpad 2.2.3 visit its milestone page.

If you come across a bug, please report it!

See you at the end of the month

Our second release for April — 2.2.4 — is due on the 29th of April.

In the meantime, stay up to date with Launchpad news and views here on our blog.

And as always, you can join us in #launchpad on Freenode and on the launchpad-users mailing list.

2

Official bug tags

Published by Tom Berger April 1, 2009 in Bug Tracking, Cool new stuff

In the latest release of the Launchpad bug tracker, we have introduced a new feature: official bug tags. Tags blessed by the project team as official display using a darker colour on the bug page, and are placed prominently at the top of the tags list on project pages. Users can still add tags that are not endorsed by the project as official, but they are encouraged to use official tags where possible.

Tags are a great way to group bugs together, and their free-form nature allows all users participating in bug tracking to invent new and interesting ways to categorize bugs. Many projects, after working with bugs for a while, discover that some tags fit their process. That using a certain tag is particularly helpful, or even required, to facilitate a regular routine. With official tags, the project team can indicate to the community what tags are encouraged, and use that to steer users away from duplication and ad-hoc invention and towards standardization.

To decide which tags are official for your project, go to the project’s bugs page and click the link at the bottom of the tags list. The management screen has two columns. On the left, highlighted in yellow, is the list of official tags. The list on the right is of all tags currently in use. To make some tags official, select them in the right-hand column and click the left arrow button. The tags now appearing in the list on the left hand are official ones. You can also add a new tag to the list of official tags. When you’re done, click the Save button to record your changes. As an alternative, you can set the official tags for your project using the web service API.

We hope that official tags will help projects become better at tracking bugs consistently. We sure waited for this as Launchpad users, because until now we used to enforce the use of official tags, documented on the wiki, manually. Future work will expand and improve on this. Maris has written an amazing auto-complete widget, which will be used for tagging bugs starting in the next version and suggest to users what tags they can use as they type. We are also looking to let anyone who is a bug contact edit the official tags list, and in the longer term, also provide a way for project groups to share official tags and for allowing teams to document their chosen tags. Let us know how official tags are working for your project.

Previous Entries
Next Entries