8

Import translation templates from your project’s Bazaar branches

Published by Henning Eggers April 1, 2009 in Cool new stuff, Translations

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.

4

People and teams get multiple Personal Package Archives

Published by Julian Edwards in Cool new stuff, PPA

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:

https://launchpad.net/~mythbuntu/+archive

Which is now:

https://launchpad.net/~mythbuntu/+archive/ppa

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 .dput.cf 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!

0

Opening the AJAX flood gates

Published by Martin Albisetti in Coming changes, Cool new stuff

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:

1

Launchpad update: April 1st maintenance window increased to 3 hours

Published by Diogo Matsubara March 31, 2009 in Notifications

We previously announced a maintenance window for the Launchpad 2.2.3 release
for one hour.

Due to some issues found during our pre-release quality assurance, we need to increase the maintenance window to three hours.

The new maintenance window is:

Going offline: 22.00 UTC 1st April
Expected back: 01.00 UTC 2nd April

We know downtime really sucks. But while you wait just imagine all the fantastic stuff that you will get with our best release ever, version 2.2.3!

Hang in there while we make the final adjustments in delivering it to you.

4

Who’s using the Launchpad API?

Published by Karl Fogel in API

People are starting to integrate Launchpad into applications, talking to it directly through its API — either by using the launchpadlib Python library or by doing RESTful HTTP requests.

Below are some of the uses we’ve found — if you know of some not on this list, please tell us (in the comments here is fine). This is partly to help us see what areas of the API are getting the most mileage, and partly because this collection might be a good resource for people who want example code for using the Launchpad API themselves.

(Note: we’ve now collected this information into a Launchpad API Usage directory, and will maintain the list there from now on.)

See also the API category on the Launchpad Blog, which has posts with code examples, news, etc. And this thread on the Launchpad Users mailing list may accumulate more examples, even after this blog post goes up.

0

Launchpad maintenance 27th March and 1st April

Published by Matthew Revell March 24, 2009 in Notifications

We have some planned maintenance and the release of a new version of Launchpad coming up, both of which will mean a short period of down-time.

PPAs offline for 30 minutes on the 27th of March

Important update: We originally announced the PPA down-time as happening on the 26th March. Due to some scheduling conflicts, we have moved the PPA down-time to Friday 27th March.

We’re upgrading one of the servers we use to provide Personal Package Archives, which will result in 30 minutes of down time on Friday 27th March.

Going offline: 16.00 UTC 27th March
Expected back: 16.30 UTC 27th March

During that time, you’ll be unable to upload to or download from Personal Package Archives.

Launchpad offline for one hour on the 1st of April

We’re releasing the latest version of Launchpad — 2.2.3 — on the 1st of April. All of Launchpad will be offline for around an hour while we roll-out the new code to our servers.

Going offline: 22.00 UTC 1st April
Expected back: 23.00 UTC 1st April

0

Linking project releases in Launchpad to milestones

Published by Curtis Hovey in Coming changes, Projects

In our 2.2.3 release of Launchpad — due 1st of April — we’re strengthening the relationship between milestones and releases.

Project releases will be explicitly linked to a milestone, meaning the release inherits the milestone’s series and identity information.

You’ll be able to create a new release from a milestone page or, if you don’t yet have a milestone, there’ll be an option to create a release and its parent milestone simultaneously. You can still have milestones that do not correspond to releases.

Just as now, the release will hold the release notes, changelog, date released, and any downloadable files.

What are Releases, Milestones, and Series?

Launchpad hosted projects can arrange their development into Series, which contain Milestones to which bugs can be targeted, and Releases which hold download tarballs and have release notes. Although Milestones and Releases go together, they were previously managed separately in Launchpad. Now they’re more unified.

Why are we doing this?

Many people already use releases and milestones in this way. Milestones aid release planning, and help people understand a project’s goals. Creating a release directly from a milestone implies that the milestone was reached.

Linking milestones to releases improves the data consistency between projects. With good milestone and release information, Launchpad can improve the presentation of series to explain what has happened, and what will happen. We hope that this will make it easier for people to know where and when to make contributions to your project.

This change also allows us to redesign the series, milestone, and release pages. Our goal is to better present the history and future of a project, as well as to improve the workflow for planners.

What you can do

You do not need to take any action regarding releases. We’re migrating existing releases by linking them to a milestone, or if there isn’t an appropriate milestone, creating a new one.

You can use Launchpad’s staging environment — https://staging.launchpad.net/ — right now to check what your releases
and milestones will look like under the new system.

We’d value your feedback so we can improve the data migration script. If you come across a problem, please report a bug here:

https://bugs.launchpad.net/launchpad

For other comments, send us an email to feedback@launchpad.net

How we’re making the migration

The release’s project, project series, version, code name, and summary come from the milestone it’s linked to. The release’s version will come from the milestone’s name.

When a release and a milestone share the same series and version/name, they are linked. The release’s summary will be appended to the milestone’s summary. You should review your project’s milestones. You can make changes to your project’s milestones and releases on launchpad.net to ensure they are merged correctly on staging.launchpad.net before the final migration.

When no milestone can be matched to a release, a new milestones is created from the release’s information. The milestone is not active, they will only appear on the project’s milestone page. There are a few instances where two series have a release of the same name. Milestone names are unique across a project. So the milestone’s name will contain the release’s version and series name (0.9-series-trunk). You can prevent this from happening by renaming some of your project’s releases on launchpad.net now — in most cases, the duplicate release name is on an obsolete series, or trunk. You can view all your projects series at:

https://launchpad.net/<your-project>/+series

We’re also taking the opportunity to rename a couple of things: description” becomes “summary” and the milestone’s visibility flag (in the REST API) is renamed to “active”.

We believe this change will make releases and milestones much more useful. Please do report bugs or email us if you have any comments.

10

Gmail filters for Launchpad bug email

Published by Matthew Nuzum March 13, 2009 in Bug Tracking

I get three kinds of email from Launchpad generally:

  1. Regarding bugs I’ve reported or specifically subscribed to
  2. Those assigned to a team I’m a member of
  3. A very occasional question or notification about a code branch I’m subscribed to.

Of these above the second is the most voluminous and the first group is the most important. However sometimes items from group two can be important, depending on the project. Launchpad includes headers for filtering email which I’ve used in Thunderbird. I’ve not been able to create sophisticated filters in Gmail though. Until now.

In the past I just grouped all Launchpad email into a folder. This folder fills up very quickly though and it becomes a burden to identify which items need my action and decreases the effectiveness of Launchpad’s bug tracking. By creating a Gmail label for different kinds of bug email I can better attend to the messages in the proper order.

Here’s my set-up: I use Evolution to access Gmail via IMAP during the work day. Otherwise I use the Gmail web interface. I want the filtering to happen all the time so I use Gmail’s filtering, not Evolution’s. This limits our capabilities significantly. Well, maybe not … read on. 🙂

The trick is to look at the emails for something that Gmail can search on and are constant among emails you want to group by. This prevents us from using the subject or the sender or the recipient. :-/

My end result is to have a label for bugs assigned to or reported by me (including bugs I’ve subscribed to) and one label for each group or project I’ll get bug notifications from. I’m naming the labels Bugs/me, Bugs/artteam (for the Ubuntu Art Team), Bugs/website (for the Ubuntu website) and etc.

I found that all bug email is shown if I search for bugs.launchpad.net. So I’ll use it for all of my searches. I also noticed that the bottom of each email tells me why I got the message. For example, “You have received this email because you are a member of the group Ubuntu Website Editors.” That is the key. Therefore I can do a search like this:

bugs.launchpad.net "Ubuntu Website Editors"

This will show me all of the bugs for that team. I can then create a filter and put that search string in the “Has the words:” field and do a test search.

We’re set. I click next and set the rules:

"Skip the inbox" is checked
"Apply the label" -> Choose "new label" -> Name my new label Bugs/website
"Also apply filter to x conversations below" is checked

Then I click “create filter.” The interesting thing above that I’ve not mentioned yet is the label I chose. By creating a label with a / in it then when accessed via IMAP it will appear as a folder. So if I go on to create labels called Bugs/artteam and Bugs/me my IMAP client will show a “bugs” folder with three sub folders.

Speaking of Bugs/me, this filter is different than the others. The search string I used here is:

bugs.launchpad.net ("direct subscriber" | "bug assignee")

Any bug that gets assigned to me or to which I subscribe is put in the “me” folder. Because Gmail’s labels are different than true IMAP folders it means that some email threads will show up in multiple places.

I’ve only implemented this solution today so no long-term testing has been done yet, but already I’ve been able to burn through a huge backlog of bug emails simply by marking as read the bugs in entire folders and focusing my concentration on the “me” folder.

There are a few emails (about 20 in the last year or so) that didn’t get caught by the filter. A couple pre-date changes in the way Launchpad sends its emails. Others were related to “answers” and subscribed branches. The volume is so small that I foresee being able to deal with these special cases as they appear in my inbox. Maybe you have more of these special cases than I do. I hope that my explanations above are clear and you can adapt the solution to your own mailbox. Feel free to leave comments about your adaptations so that others can benefit from them.

**Bonus tip:

Do you use Gmail all the time? If so you can have your labels appear as folders that can be expanded and collapsed, just like in an IMAP email client. There are two ways to accomplish this, the simplest to install is the “Better Gmail 2” extension for Firefox, the other is the “Folders4Gmail” Greasemonkey user script. “Better Gmail” is a compilation of stand-alone Greasemonkey user scripts including the Folders4Gmail package. I decided I didn’t need most of those features and already had Greasemonkey so use only the Folders4Gmail.

4

Inside the Launchpad AJAX Sprint: A Week with Widgets and YUI 3

Published by Maris Fogels in General

Recently ten people from Launchpad and other parts of Canonical came together in Berlin to hack on Launchpad’s new YUI 3 JavaScript interface.  The sprint was tremendously successful, producing four fully functioning YUI 3 Widgets, complete with test suites and live demo pages.  This post offers a look inside the event, and some thoughts about what made it so successful.

The sprint brought together one member from each of Launchpad’s teams, as well as Martin Albisetti, for his design insight, Francis Lacoste, for his Zope3 and Launchpad architecture knowledge, and Stuart Langridge, who, to our surprise and fortune, had much jQuery, DOM, and CSS experience.  This wasn’t the team’s first encounter with the YUI 3 JavaScript library (we had spent two weeks in the fall reviewing JavaScript, YUI 3, and client-side development), but this would be our first time taking YUI 3, and Launchpad’s JavaScript support, up to full speed.

Martin kicked off the morning of day one with a walk through some video proof-of-concepts that we would bring to life.  After some wide-ranging discussion and dealing over implementation details, we spent the afternoon looking at the technical side of YUI 3 Widgets.  At the end of the day eight of the sprinters split into pairs, each pair picking a widget to work on.

Day two saw the four teams plan their attack, then dive into the code.  The sprint took on the shape of a massive parallel experiment, with each team choosing a different development approach: one wrote tests first, diving into Test Driven Development; another executed a two-pronged assault, with one person writing the widget while the other worked on Lauchpad integration.  A third team went for functionality first, aiming for a working wireframe before styling the page, or writing tests.  In the end none of the approaches was a clear winner, but it’s worth noting that quickly getting a working prototype up on the projector gave everyone a huge moral boost, and looks to be worth the cost of that team writing their tests last.

One thing that helped every team get up and running quickly with the YUI 3 Widget framework was having an already-running, fully integrated widget in Launchpad: the inline-text editor for Bug and Project titles.  Building the inline editor had cleared paths for coding styles, directory structure, test harnesses, and all of the Zope3 integration code.  A month or two of work had already gone into supporting JavaScript and JavaScript testing in Launchpad — now that work paid off, giving all eight people a very fast ramp-up to code that could land in mainline.  Along with the very well-written YUI 3 docs, everyone was writing code by noon.

Day three saw more code, tests, and our first working widget.  We just needed the fancy frame to have a pixel-perfect movie match.  The teams kept the momentum high all day while Martin, Francis and I criss-crossed the room, lending design decisions, on the spot integration plans, and YUI advice and council.  Stuart Langridge also lent his scripting and CSS experience to the effort.  For any sprint, when the team is blocked on an implementation question, it helps to have someone with the authority to make final, on the spot decisions.  We discovered that, when doing top-to-bottom JavaScript widget implementation, it helps to have a whole team of them.

By noon of day four most of the remaining widgets were functional, if not fully styled.  For me, much of the day was spent pair programming, tackling a subclass of the YUI Overlay widget.  We had trouble getting it to accept the stylish drop-shadowed frame given to us by our designer, and we used YUI 3’s JavaScript unit testing library, yuitest, to work around it.  Our test suite allowed us to spot the Firefox DOM bugs our layout triggered, and assured us that our hackish workarounds unbroke the DOM tree.

Most of the sprinters were qualified code reviewers, so day four’s afternoon was spent in a team review of the fully functional fancy Overlay widget: two authors presenting with Emacs, one scribe, and seven people contributing questions and comments.  The meeting helped immensely in building a culture around JavaScript code in Launchpad, and left us with a draft JavaScript style guide, and a coding standard we could take to the wider team.  I highly recommend such a review, along with the surrounding discussion, to anyone bringing a new language into a programming group.

Everyone had great momentum going into day five.  All four widgets were fully functional, with only a few rough spots remaining.  One nasty Friday surprise was that the original inline editor didn’t work in Konqueror 4.1 — in fact, it made editing Launchpad Bug titles impossible.  This is where our adoption of YUI’s Graded Browser Support and Graceful Degredation really shone.  We quickly made the decision to give KHTML browsers a C-Grade experience: for them, the site behaves as if it were not enhanced with JavaScript: you can still edit a bug title, but you are taken to a new page to do so.  The decision was fast and simple, and with a clear C-Grade verdict of “No JavaScript”, no unnecessary time was spent searching for other fun issues the browser may have presented.

Day five’s afternoon was spent with everyone in a Review Jam.  We mixed up the programming pairs, with one person from each team reviewing someone else’s code, using the guidelines we had drafted the previous day.  Martin did some final user interface design reviews, and everyone left that Friday with a list of changes before final submission to mainline.

The sprint was very successful, one of our best yet, producing four YUI 3 widgets in only three and-a-half days of coding, and we plan to have another sprint like this in the future.  Here’s some of what made this week-long coding sprint work for us:

A final word on YUI 3: the library performed very well, especially given its pre-release status.  Experienced scripters may find working with YUI 3 a little odd at first, because you are not working with the raw DOM: you have to get used to using YUI Node instances, getters, and setters, instead of DOM object properties (most of the DOM methods are passed right through).  However, once past the initial bump, you can quickly see the advantages of having features like object property getters and setters, a robust and advanced object construction system, and cross-browser APIs.  Stuart also pointed out one big, open question about YUI itself: the only major libraries to tackle JavaScript widget development “in the large” are YUI and Dojo.  We’ll see if YUI’s large approach, jQuery’s small tools approach, or YUI 3’s mix of both is best.

4

Shutter

Published by Matthew Revell March 11, 2009 in Projects

The Shutter logoScreenshots are screenshots, right? If whacking the “Print Screen” button doesn’t offer enough refinement, then surely firing up The Gimp, gnome-screenshot or knsapshot would give you what you need, wouldn’t it?

The team behind Shutter would disagree. I was interested to know what would motivate someone to develop a new screenshot app, so I asked Mario Kemper why he began work on Shutter.

Mario: Well, I am a computer science student working as QA person in my freetime. When i started to do the QA work I was looking for a neat screenshot application because we are doing a lot of documentation for the developers as well.

There were some apps like ksnapshot, gnome-screenshot etc. but they all focus on a single screenshot; no editing features, no session, no nice effects etc. So i started to develop Shutter (formerly gscrot) with these features and goals in mind.

There is another big point, though: we all spend much of our time in forums, wikis, chats etc. From time to time we need to do some screenshots and upload them so we can share them with other people so i wanted to have a built-in function to upload your screenshot with nice link-formatting so you can post the generated link directly in the forum, wiki etc.

Shutter uses Launchpad for bugs, code, translations, answers and blueprints. You can get hold of Shutter from the Shutter team’s Personal Package Archive.

Previous Entries
Next Entries