You’ll need a PGP key registered in your Launchpad account if you want to use the bug tracker’s email interface, sign a Code of Conduct or upload a package.
There’s a guide in the help wiki and also now this screencast!
On the 28th September, the Canonical Launchpad team leads will be in London, along with myself, community guy Karl Fogel and UI guy Martin Albisetti.
I’m organising a Launchpad community meet-up for the evening of the 28th, which will be a chance to meet other Launchpad types, including several of Canonical’s Launchpad engineers.
We’re considering a couple of different venues at the moment but it’ll most likely be a pub in central London and fairly informal.
If you think you’ll be able to make it along, let me know. More details soon.
There used to be only one way of exporting translations from Launchpad—by requesting your files in the Launchpad UI and waiting for an email with the download URL. It works, but it’s not very convenient if you’re trying to automate things. It’s not that easy to make the request automatically, and then right in the middle of your script you also have to wait for the email, catch it, and parse it to get the file.
Now there’s another option: automatic exports to a Bazaar branch. If you set up this option, Launchpad will regularly produce a snapshot of your translations and commit it to a Launchpad-hosted branch of your choice. Now you can always find a reasonably fresh export of your translations in the same place, and download it automatically, without any asynchronous requests.
It also means that large numbers of developers or translators can get regular, fresh updates of the translation files.
Let’s say you have a project called bzamqi. It’s set up for translation in Launchpad, and you want regular translation exports of the 1.0 release series.
The first thing you need is a branch. It doesn’t have to be a branch for the bzamqi project, but you do have to be the owner. (The branch can belong to a team, but then you do need to be a direct or indirect member of that team.) The Launchpad help wiki describes various ways to create a branch:
Just remember that the branch must be Hosted, i.e. the master branch must be stored on Launchpad where we can commit to it.
Update: at the moment, team-owned branches don’t work. To work around this, make yourself the owner of the branch; set it as the translations branch; and then make the team the owner of the branch again.
Now, go to the page for bzamqi’s 1.0 release series. You’ll be wanting the Translations tab. Once there, pick the Settings option.
On the page that takes you to, near the bottom, there’s a section “Export translations to branch.” You can set a branch there, and translations for the series will be exported to that branch.
If you want to disable the exports, go back (use the “pencil” icon next to the branch name to select a different branch) and select no branch at all. Just clear the input field. The settings page will go back to how it was before you selected a branch.
The main thing to grok is that this is not Launchpad “editing” text files for you. The export brutally overwrites any previous versions of the files in your branch. In the file that Launchpad writes, translations may have changed—but messages may also appear in a different order, or with different comments, and so on.
So do not expect files that you can merge back into the originals without any further work! The Launchpad database and bzr have completely different views of this data. There is a trick though; see the “Advanced” bit below. Also, it will help to keep the messages in translation files in the same order in which they appear in the template.
In the branch, each translation file will have a normalized name (de.po for a German translation, zh_CN.po for Simplified Chinese, eo.po for Esperanto, and so on). Each translation sits in the same directory where its template was on import.
If you have multiple templates, make sure that they have different directory paths, or the translation files for one will overwrite those for the other! It was already recommended practice to give each template its own directory.
Templates are not exported.
It is possible to import translations from and export translations to the same branch. If you push changes to a translation file into the branch, the export will not overwrite the changed file unless your updated file has already been copied onto the translations import queue.
Of course it’s still possible for the import to fail for whatever reason, and in that case your file will be overwritten. This hopefully won’t hurt; the file that’s being exported is “better” in the sense that it shouldn’t cause any import errors. But it may not always be what you want, so be careful if you do choose this setup.
(Your templates will not be touched, since the export doesn’t write them.)
Don’t use this “two-way” setup lightly, since it complicates things. Complications are where accidents happen. Either wait until there’s more practical experience with this, or make sure in some way that you won’t lose data if something goes horribly wrong.
A bit less adventurous but still useful is to have only your templates imported from a branch, and have your translations committed to the same branch.
For now, once a day. We may tweak that later depending on how much this feature is used and how heavily it loads the servers.
If the export runs at a moment when you’ve pushed changes into the branch that Launchpad hasn’t processed yet, the export will not happen. This is a deliberate protection against conflicting updates. Unless you update your branch all the time or just at the wrong time of day, the next day’s export should catch up with the latest changes.
Otherwise you would be making Launchpad write data into someone else’s branch. Not a nice thing to do to someone who isn’t expecting it!
If you want someone else to own the branch, you can change who owns it later, using the normal branch settings UI. You only need to be the owner when you set it as the translations export branch.
The exports keep happening to the same branch. If that is not what you want, it’s up to the remaining project owners to choose a different branch or disable the exports.
William Grant was the first person outside Canonical to submit a patch to the newly open sourced Launchpad. I asked him a few questions to see how he got on.
Matthew: What did your patch change?
William: Launchpad users may elect to receive the bug’s description and status in the footer of each bug change notification email. This helps keep track of context when dealing with lots of different bugs.
Previously, bug emails that got to you through a team wouldn’t respect the setting — email coming through some teams would have the description, but for other teams it would be omitted. My fix ensures that the user’s selection is respected even for team emails.
Matthew: Why did you take the time to contribute to the Launchpad codebase?
William: I use Launchpad Bugs a lot, and get a lot of bug mail. This is an issue that has been irritating me for some time, and the fix seemed simple enough, so I decided it might be a good first task.
Matthew: How was it finding your way around the source tree?
William: It was easier than I expected. Most of the Bugs code now conveniently lives in lp.bugs, so I wasn’t overwhelmed with having to deal with the whole tree at first. The extensive test suite (particularly some good doctests) pointed me in the right direction, and developers and grep showed me the rest.
Matthew: How easy/hard was it to make your changes and stick to the Launchpad coding guidelines?
William: I didn’t get it quite right at first, but once pointed at the guidelines, it was simple to make my code compliant. It ended up looking a lot cleaner.
Matthew: What about the review process?
William: Remarkably easy. I found a reviewer (Graham Binns) on IRC, and submitted a merge proposal for my branch. A couple of hours and a few test changes later, my branch was approved. Graham landed it as soon as PQM reopened.
Matthew: What advice do you have for other people considering writing a patch for Launchpad?
William: Do it — it’s great to be able to fix those issues that have been bugging you for ages, and it’s not as hard as it looks. The test suite is a great guide through much of the codebase, and there are always developers on IRC to point you in the right direction if you get lost. The reviews are quick, developers are friendly, code style guidelines are clear, releases are frequent… all up it’s a very pleasant experience.
Matthew: Thanks William!
Last month we made a small change to the series page as a commitment to making a distinction between the driver for a project and the driver of a series. The drivers of a project have the power to make the decision of what features go into a release. But the driver of a series is special. Often a select number of individuals are delegated the awesome responsibility to define the intent of a series, manage all the milestones necessary to meet the goals, and to create the release. Series drivers are release managers.
When developers talk about the trusted persons who are making the release happen, they use the term release manager. While Launchpad recognised the role, it required the person also be a project owner, which is not always suitable for large projects. Release managers do not need the power to edit the project information, they need the power to edit the series information, create milestones, and release them. That is the power they now have.
A project owner can set a user, or a team as the series release manager from the series page. Project drivers also have the power to create a series; they have the power to start planning to be make themselves the release manger of the series they create.
Distribution have release managers too, they have the same responsibilities as project release managers, but giving them power is a bit tricky. For distributions other than Ubuntu, release managers will be able to create series and milestones, and edit their details just as a project release manager.
Ubuntu must be handled as an exception; the gift of Soyuz and Translations is also a curse. Many special tasks must be performed before an Ubuntu series can be register a series in Launchpad. The release managers for an Ubuntu series will have more power to edit the series details and milestones.
Launchpad has supported assigning questions to users for several years, but the privilege was limited to project owners. This meant the feature was rarely used. Since the feature was also not visible, answer contacts often requested that we develop the feature. Question listing now include the assignee column. Answer contacts can assign a question to a user via the edit page. The assigned user will receive a notification about the assigned question. An assigned question will never expire; the assignee is obligated to answer the question.
The launchpad team had considered removing this feature two year ago because it was not popular. There were a few users who explained the need to assign questions to knowledgeable or privileged answer contacts. Simply put, the problem was not that assignment was unwanted, but that it could not be used by the people who needed the feature. The Launchpad team did not really understand how users were trying to use Launchpad until we decided to take turns answering every question asked to the launchpad project. We soon understood the need to assign questions to users. There are many questions that can only be answered by one or two people. The assignment must be visible to everyone, otherwise you would spend an hour reviewing open questions that were already assigned to someone. The cruelest part of assignment that that the assignee was never told that he has a task to complete.
This situation was especially frustrating for me because Answers is the application I started working on when I joined the Launchpad team. I knew that I could fix the issues in a few hours of work. Answers however, is not an application we are developing at the moment, I could not work on it during work hours. So I decided to fix the assignee feature on a Saturday. I could do this because the Launchpad on-call reviewer cannot easily say no to a merge request for a branch. I was also pretty certain my branch would be accepted because the reviewer is also answer contact who has experienced the assignee problems too.
The on-call reviewer rule is in place to ensure every patch is reviewed and given an opportunity to merge. This rule applies to everyone. Some Launchpad users have submitted patches for Launchpad pages and scripts and we have reviewed and merged them. Launchpad is now open source. You too can submit a branch knowing that someone must review it. Many of the Launchpad team members hack on Launchpad on our own time because we love Launchpad. Yet we still cannot fix every bug, or implement every feature. There are a lot of bugs that can be solved in a few hours work. If you want help to close a issue that you care about, we can help. Again the on-call reviewer is obligated try to advise on implementation issues. Also, Launchpad developers prefer to have pre-implementation plans to ensure that when someone decides to start a branch, it can be completed in less than two days and will be accepted by a reviewer. Someone on the #launchpad-dev channel on freenode can help.
Now that we’ve released Launchpad’s source code, our next couple of months of work are going to be mostly focused on our page layouts.
Launchpad has been around for quite a few years now, and tight release schedules packed with ever-changing features have had the side effect of us ending up with a lot of pages with different layouts.
In the next 2 months, we plan to fix that, and make sure every single page in Launchpad (452 templates!) has our new “3.0 look n’ feel”.
What does that look like, you may ask yourself?
Well, we’re still working on it, as we’re going to change the UI for the navigation (as well as tweak it’s functionality a bit, more on navigation in a future post). We do have rough draft which we’re starting to work towards, figure out what works and what doesn’t with real data, things we didn’t think about, etc.
The first major page we’re converting is the project overview page, currently being worked on by the world famous Curtis Hovey, and the initial draft should look similar to this:
It’s important to note we’re still working on the UI, so the image above is our starting point rather than the end product.
Since it will take some time to make all the changes, we’re most likely not going to make a Launchpad release in August, and jump straight to September. Roll-outs to our edge server will continue to happen daily, and we’ll need your feedback on the changes more than ever. If you’re interested in helping us, just join the beta testers team.
Exciting times! 🙂
This is a post I’ve been looking forward to for a long time:
Launchpad is now open source!
We released it today under the GNU Affero General Public license, version 3. Note that although we had previously announced that we’d be holding back two components (codehosting and soyuz), we changed our minds: they are included — all the code is open.
Big congratulations (and thanks) to the Canonical Launchpad team, who worked overtime to make this happen sooner rather than later, and to Mark Shuttleworth, whose decision it was to open source Launchpad in the first place.
Rather than repeat the various release announcements, I’ll just point to them:
The Canonical Launchpad developers will be on IRC in channel #launchpad-dev on irc.freenode.net. That’s the place to go for real time development discussion and questions. For usage issues, #launchpad is still the place, as before.
The mailing list is launchpad-dev {AT} lists.launchpad.net, which you can subscribe to by joining the ~launchpad-dev team. Again, that’s the development mailing list; user questions should still go to launchpad-users {AT} lists.launchpad.net.
Please bear with us as we learn how to be an open source team. Many of the Launchpad developers have open source experience already, of course, but as a team we’ve been working on Launchpad in-house for some years. This is a big change. We’ve been looking forward to it, though, and are ready and eager.
That’s all. Happy hacking :-).
-Karl Fogel
I’ve set up a Launchpad channel on YouTube. Along with other members of the Launchpad team, I’ll be posting tutorials, demos of new features and more.
If you have a request for a video you’d like to see, file a bug in the Launchpad Documentation project! Or make it yourself and get in touch.
To kick things off, there’s a video showing the new in-line tag editing on bugs pages.
Update: I neglected to mention that all our videos are also online in Ogg Theora format.
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.
Terms of use | Help improve Launchpad | FAQ
Launchpad Blog by Canonical Ltd is licensed under a Creative Commons Attribution 2.0 UK: England & Wales License. 
© 2004-2019 Canonical Limited.