launchpadblog

If you’re using edge, you can now just comment on a question in Launchpad. For all questions on Answers, the “Just Add a Comment” button is now always visible.

Previously, you might have only seen “Add Answer” and “Add Information Request” (or others; the exact buttons vary), both of which add a comment and cause the question status to change. But often, for example, all you want to do is clarify an earlier comment, add some detail, or give a progress update. For that, “Just Add a Comment”.

It’s been put at the rightmost position of all the buttons because we think it should be the least used option. Normally it’s appropriate to use one of the other buttons to move the workflow forward.

The button will land in production with the 3.1.10 release next week.

Over the past few months we’ve been slowly introducing a grand new feature in Launchpad Translations, and with 2.2.7, we are finally ready to announce it to the wide world: message sharing.

Introducing message sharing

Message sharing between different releases of a product or distribution in Launchpad means that translations done in one release (eg. trunk) would immediately apply to translations in another release (eg. stable). This should benefit everyone using Launchpad for translations, one way or another.

• Translators will not have to worry about back-porting translation fixes to older releases anymore, and they can simply translate the latest release: translations will automatically propagate to older releases. Also, this works both ways, so if you are translating a current stable release, newer development release will get those updates too!
• Project maintainers hosting their translations in Launchpad, when they upload a template to a new release series and it gets imported, will instantly get all existing translations from previous releases shared with the new series and translators won’t have to re-do their work. They won’t have to worry about uploading correct versions of translated PO files, and can just care about POT files instead.
• For Ubuntu, there’s another benefit: opening a new release for translations will take minutes instead of days. Message sharing also improves the scalability of the system, and we should soon start seeing more performance improvements as the result of migrating to this new way of managing translations.

How to benefit from message sharing?

Over the next few weeks, we’ll be migrating all existing projects to make the best use of message sharing. If there are any potential problems with existing projects, we’ll be emailing their maintainers and resolving it as we go along. Messages will be shared only between templates in one particular project, and only if they all have the same name. For Ubuntu, they will be shared only between templates in one particular source package, and again, only if they are of the same name.

For example, Ubuntu Jaunty and Ubuntu Karmic already share their messages. If you update a translation for one single string in Karmic GNOME Panel, and that same string exists in Jaunty GNOME Panel, Jaunty translation will be instantly and automatically updated to exactly the same translation.

If you want one particular release to have a different translation from all the other releases, that’s still possible. So, if you do not want a translation in Jaunty to be modified when a translation is changed in Karmic, you have that option too. Since we don’t expect this option to be used often, it’s hidden in the “zoomed in” view on each single message.

What next?

We’ll have to carry out a data migration for each of the projects using Launchpad Translations. Luckily, this migration will be completely transparent, so there’s nothing for anyone else to do. On the outside, nothing will change, until you start doing translations for more than one release series, when they’ll just be better.

New projects will get benefits of message sharing right away, and existing ones should be a bit patient because doing the migration takes some time, but allows to keep the full history of translations intact.

If you are interested to learn more, come talk to us on #launchpad on FreeNode, or join the launchpad-users mailing list.

Launchpad has a little known feature that is getting better. The product release finder is a process that runs everyday to locate new releases and import them to Launchpad. The process uses the series’ Release file pattern to locate files and import them to the appropriate release. It can even create releases for series. The process is robust and worth consideration if you want to upload large release files for your project.

The project owner and series release manager can set the Release URL pattern by the series edit page. The pattern is an ftp, http, or https URL with a glob (*) in the part of the file name that varies with each release for a series. For example:

http://widgets.dom/downloads/widget-2.*

describes all files that start with ‘widget-2.’. This might be the source for two different releases, widget-2.1.tar.gz and widget-2.2.3.tar.gz. The pattern will also match multiple files that belong to a single release, such as widget-2.1.tar.gz, widget-2.1.zip, widget-2.1.changelog.

Many projects choose to group files in series in a directory of their own, in which case the Release URL pattern would look something like:

http://widgets.dom/downloads/2.8/*

You can tell the product release finder to search multiple directories by using a glob for a directory. For example, if your project separates release files in directories for each OS then you can try

http://widgets.dom/downloads/*/widget-2.*

to scan downloads/ubuntu/widget-2.* and downloads/mac/widget-2.*.

Be careful to include the common part of the series in the URL, otherwise files from different series will be imported to the wrong series. Do not do something like:

http://widgets.dom/all-releases/*

because any file that looks like it has version information in it will be imported to one series.

In all cases, the product release finder will extract the version from the file name, and match it to a milestone name. It will create the milestone and release it if necessary. If a version cannot be extracted, the file is ignored.

The version numbers extracted from file names conform to Launchpad URL name rules. So if your release files have underscores or pluses in their version names, dashes will be substituted. Flavour information is also ignored in the file name. For example these file names yield these versions:


emacs-21.10.tar.gz => 21.10
vpnc-0.2-rm+zomb-pre1.tar.gz => 0.2-rm-zomb-pre1
warzone2100-2.0.5_rc1.tar.bz2 => 2.0.5-rc1
furiusisomount-0.8.1.0_de_DE.tar.gz => 0.8.1.0
glow-0.2.1_i386.deb => 0.2.1
Bazaar-1.16.1.win32-py2.5.exe => 1.16.1


What’s Next

The product release finder should notify owners and release managers when there are problems with imports. A lot of problems were fixed recently, but there are two issues we are still seeing in the logs that indicate the Release url pattern must be updated for some projects. The product release finder cannot access the server or directory in some of the URLs. There are also a few URLs that have no glob. They appear to be the URL to a single file, where a glob is needed so that the series can have many releases. If the product release finder does not find your files after a few days, review the Release url pattern and check the remote site to verify they are fine.

We will update the UI to make the Release url pattern more prominent, and easier to set for each series.

You may have noticed that we introduced some useful new options when filing bugs. These are especially useful to anyone who files lots of bugs.

Something for everyone.

Everyone can now set tags when filing a bug. Previously, only people going via the advanced bug filing page would have the option.

One caveat: the tag field is not yet wired up with the magical tag auto-completer that you can use on the bug page itself, but that’s coming.

Something for bug supervisors.

If you’re filing a bug against a project for which you’re a bug supervisor, some additional fields appear in the new Extra options area (which is collapsed by default, but can be expanded by clicking on it). There are options to let you to set the initial status, the importance and the milestone of the bug, and also assign it directly to someone to work on.

If you have any problems with these new features, please file bugs against Launchpad Bugs, or talk to the help contact in #launchpad on freenode.

Up until now, series overview pages have offered a historical overview of a series. Today, we’ve released our new series overview pages that work much more like a dashboard for people driving a series.

Before we look at the new dashboards, let’s clear up some terminology: to clarify the difference between the roles, we’ve changed the name “series driver” to the more familiar term “release manager”. Most projects use series as lines of development that result in one or more releases and so it makes sense to reflect that in the role’s name.

Project drivers remain as they are.

So, back to the new series dashboards: take a look at the page for Drizzle’s trunk series and you’ll see that the page now has a whole load of information that makes it easier to see the current state of that series. Perhaps of most interest is the Milestones and releases section.

At a glance, you can see how much work is planned for the series’ upcoming milestones and the progress being made with those blueprints and bugs.

Further down on the page you get links to the series’ mainline Bazaar branch and details of packages associated with the series.

If you’re a series release manager, let us know what other information you’d find useful on the series dashboards.

New on project overview pages: project timelines.

Here’s the timeline from the Drizzle project. Straight away you can see how many series — i.e. major lines of development — are running concurrently, along with releases and milestones. Click on any of them to get more info.

Greetings, readers!

For a while now I’ve been the Launchpad developer in charge of helping users of other bug trackers migrate their projects to Launchpad. We do this reasonably regularly for users of Trac, SourceForge and Bugzilla, and we’re always open to helping people migrate from other solutions should they wish to.

Several months back, the Elisa project migrated from Trac to Launchpad. In doing so, they wrote a script to take their Trac database and convert it to the Launchpad bug interchange format, which is an XML schema that we use for bug imports (you give us an XML document containing your bugs that conforms to the interchange format schema and we can then import it into Launchpad for you).

More recently, we realised that we were getting quite a few requests from Trac users for help with migration. We went back to the Elisa developers and asked if they’d be willing to let us have their migration tool under the GPL so that we could share it with everyone. They kindly said yes, passed the code to us under GPLv3, and yesterday I made it available on Launchpad as the Trac to Launchpad Migrator project.

It’s a bit rough around the edges at the moment and needs some documentation, but more than anything else it needs people to test it and use it so that we can make migrating from Trac to Launchpad as smooth as possible.

Update: Matthew’s written a blog post about our bug import format.

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.

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.

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 code.launchpad.net using Bazaar branches. You also have a great translation tool in translations.launchpad.net 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.