Archive for the ‘Cool new stuff’ Category

In-line bug tag editing and subscriptions

Wednesday, May 27th, 2009

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.

Official bug tags

Wednesday, April 1st, 2009

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.

Import translation templates from your project’s Bazaar branches

Wednesday, April 1st, 2009

Now grows together what belongs together. Introducing a cool new feature: importing translation templates from Bazaar branches.

You can (and should) host your source code on using Bazaar branches. You also have a great translation tool in that can help you to publish your project in many different languages. But so far, these two great applications lived seperate lives. This is beginning to change now!

How do you start translating your project into foreign languages? You start by generating a template file from your source code and uploading this to Launchpad. The translation template contains the English strings that translators are meant to translate into their language. What if the source code is hosted on Launchpad? Until now, you still had to upload that template manually to Launchpad Translations and wait for it to be imported.

Here is how it works now: generate the template file in your source tree using gettext tools, as you would have done before. But instead of uploading it, simply commit it to your Bazaar branch and push that branch to Launchpad. Now it just takes a one-time configuration step and your template file or files will be automatically imported into Translations. What’s more, this happens every time you push a new version of that file without you having to do anything.

To get started with importing translation templates from a branch, navigate to the “Overview” page of the release series of you project that you want to import translations into (usually “trunk”). Click on “Link to branch” to link this series to a Bazaar branch. If this has already been done, use this step to verify that this is really where your template file can be found. Next, go to the “Translations” page of that release series. You’ll probably see the message “No translatable templates available” but you are about to change that by clicking on “Settings” in the menu bar. Here you change the import mode to “Import translation files”. Once you click on “Save settings” an initial import of your translation templates will be triggered and you should soon find it in the import queue and shortly after that the template is available for translation work. Now, whenever you update the template file in your branch you just have to wait some 15 minutes or so and the change will appear in your translation template on Launchpad.

Read all the gory details on the help page and watch out for how in the future Bazaar branches and translations will grow even closer together.

People and teams get multiple Personal Package Archives

Wednesday, April 1st, 2009

The release of 2.2.3 brings with it a change for PPAs — we are now supporting multiple PPAs per person!

You will have probably already noticed that we made a change in 2.2.1 that altered the URLs you see for a PPA’s index page and its sources.list entry; these now have the extra “ppa” in there. This is actually the default name for the first PPA that anyone creates.
Example old-style URL:

Which is now:

You can create additional PPAs from your own profile page or your team’s profile page. You are able to name them whatever you like with one exception — we are not allowing you to name them “ubuntu”. This is so that we can maintain backwards compatibility with the old upload paths where you don’t need to specify the default PPA’s name.

To upload to the additional PPAs your upload path should look like:

incoming = ~myname/ubuntu/otherppaname

These additional PPAs will behave as any other PPA, the only difference being that they clearly belong to a person or a team, and you won’t need to create dummy teams/people to have more PPAs.

We hope you enjoy this new feature!

Opening the AJAX flood gates

Wednesday, April 1st, 2009

After many months on working on the necessary infrastructure to deploy complex AJAX widgets in Launchpad, more user interface reviews than any developer would like to go through in a life time, and a lot of cursing, the tip of the iceberg is finally showing.

Mark announced months ago the level of complexity we where aiming at achieving, and this last roll out of Launchpad actually places us very close to that.

Micheal Nelson did some amazing work, and landed the first of many pop-up widgets, allowing you to mark a bug as a duplicate without needing to refresh the page:

You will start to see that some links in Launchpad are green, those will mean that you will get an AJAX experience instead of going to another page. Check it out in bugs:

Tom Berger and Abel Adeuring also switched to javascript ninja-mode, and cooked up a slick UI for managing official bug tags:

Links to external bug trackers right where you need them

Thursday, February 26th, 2009

Linking Launchpad bugs to upstream bugs can be hard work. You don’t necessarily know whether the bug is reported on the upstream tracker, and if you don’t know where the upstream project tracks its bugs you have to go and find out before you can file the bug and link the Launchpad bug to it.

We understand that this process can be a bit of a pain, so we’re introducing a feature that should make linking to upstream bugs a bit easier: Launchpad will now give you direct links to the bug search and filing forms in a project’s external tracker, so long as Launchpad knows the location of the project’s tracker and, if the tracker tracks more than one project, which project on the external tracker the Launchpad project refers to (so, for example, Launchpad needs to know that the Launchpad project ‘evolution’ links to the ‘Evolution’ product in the Gnome Bugzilla).

And because we know that a project maintainer shouldn’t have to go back to Launchpad and add the link to the remote project when Launchpad should be able to work it out for itself we’ve fixed that problem, too: Launchpad will check all the projects that are linked to a remote bug tracker and will try to deduce which remote project they’re linked to by looking at the bug watches that are registered against that bug tracker. Of course, this isn’t an exact science, and we’ll have to correct some of these auto-generated links manually, but hopefully it won’t take more than a few days for us to straighten out the kinks.

In order to get to remote bug tracker links, all you have to do is click Also affects project on the bug report and select the project that you want to link to. Launchpad will then offer you the links.

We’re going to be working to improve this further in the coming Launchpad development cycle, so keep your eyes on this blog for further information.

AJAX in Launchpad

Friday, February 20th, 2009

After a few months of working on all the infrastructure changes needed to start deploying AJAX on Launchpad, we are now ready to start developing the mockups we’ve been working on for the past months in the User Experience team.
To make sure we coordinated the work of 35 distributed developers, and really get the ball rolling 10 of us gathered for a sprint in Berlin and went into full ninja-hacking mode for a week, while defining standards and best practices as we went along.
The outcome of the sprint has been amazing (it’s actually still going on!), and we’re very well prepared to roll out all kind of AJAX goodies like “in-line status editing”, “multi-line editing” and “person pickers” in the next few months. It’s going to be awesome  😉
We have decided on YUI3 as our javascript library, and while it is still not a final version, we are very happy with our decision and it has allowed us to do some really cutting edge work, while maintaining clean and re-usable code.

I’m also very excited about in-line text editing having landed last week in Launchpad’s edge version (used by beta testers), enabling in-line editing of bug titles and project names, which landed thanks to the amazing work of Māris Fogels and Francis Lacoste. For all you non-beta testers, you will see it rolled out late next week.

Since it got rolled out, every time I edit a bug title I get the greatest feeling when presented with this:

A lot more coming soon, so stay tuned!

PPA page performance improvements

Monday, February 9th, 2009

Last week was the first of some Launchpad Performance Weeks that we’re embarking upon. The Soyuz team worked hard on improving the performance of the PPA page, which had a tendency to be very slow or even time out on PPAs that have a lot of binaries published.

The more observant of you will have noticed that the PPA page on edge is now using asynchronous requests to fetch both the “Repository disk usage” section, and the package information section that is expanded when you click on the triangle at the left of each source package row. This means that the initial page load time is a lot quicker! There’s still some more speed we can get out of the page by reducing the query load that it places on the database server, and we’ll deliver that change soon.

We also fixed a smaller snafu — as part of the webservice work that we’re doing, we managed to accidentally enable a URL that let you view the main Ubuntu repository as if it were a PPA page. These links nearly always timed out because of the size of the Ubuntu archive, so that URL will now redirect to the /ubuntu page on Launchpad instead.

Also in the pipeline is a major overhaul of the PPA page. Watch out for that soon!

Translations style guides

Wednesday, January 28th, 2009

Finding the right balance between open access and quality control is an ongoing challenge both for translations groups and the Launchpad Translations developers.

Launchpad already gives projects the flexibility to choose what level of openness versus control that they want for their projects, through different permissions policies. While that allows you to decide who can translate and who should review new translations, until now it hasn’t been particularly easy to introduce new and drive-by translators to your way of doing things.

Now, if you’re in a translation team, you can set a link to an externally hosted translations style guide. Simply go to the translations tab of your team’s page to set the link.

Once set, a link to your style guide will appear on each translation page for which your team is responsible, meaning you have a greater chance of getting suitable strings from new translators.

Exporting translations back upstream

Wednesday, January 28th, 2009

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.