Launchpad is Go!
Published by Matthew Revell May 10, 2011 in API
There’s a new Launchpad client library, called lpad, for the Go programming language.
Gustavo writes:
lpad is based on a two-layered design. The top layer offers a static API which allows a more comfortable interaction with the API with static checks, better documentation, and more. The bottom layer is fully dynamic and enables the developer to access all the features of Launchpad, even those not supported by the top static layer.
There’s still work to do but the library is pretty much complete and it’s well tested, including integration tests which communicate with the real production servers.
You can get hold of lpad with a simple:
bzr branch lp:lpad
Check out the full API documentation.
Photo by Iain Farrell. Licence: CC BY-ND 2.0.
Doing it for the Luz
Published by Matthew Revell May 9, 2011 in Projects
Luz is a new project to Launchpad. It creates impressive visual effects that can react to music or be driven by a person using a MIDI controller or a gamepad.
It has been created by Ian McIntosh, part of a Portland, Oregon, artists collective who produce light and projection shows.
Here’s what the Luz page on the Light Troupe site has to say:
With one click, any movement or effect can dance to the beat, react to audio, or be driven directly by human input from any number of any device: Gamepads & Joysticks, MIDI knobs & sliders, MIDI Pianos & Drums, WiiMotes, Wacom Tablets, and any app that can send OpenSoundControl.
Ian has provided a handy series of YouTube tutorials, to get you started. If you want to try it out, here’s the first of those tutorials:
launchpad @ UDS-O
Published by Francis J. Lacoste May 6, 2011 in General
As part of determining What’s Next?, Jonathan (our Product Strategist) and I will be attending UDS Oneiric next week (May 9th – May 13th) in Budapest. If you are running a session where you need input from Launchpad, or working on a Ubuntu project that would require Launchpad infrastructure change, be sure to subscribe us to the blueprint so that we know to attend the session. It’s likely that anything major that would require a full squad probably wouldn’t be able to be completed before late in the cycle. But there are certain small enhancements that could certainly be taken as part of the maintenance squad work.
Feel free also to grab us in the corridors or in the bar to give us praise and tell us how Launchpad is working great for you! We always appreciate those stories. If you want to complain, or tell us how Launchpad could be even greater if it had this extra feature or do this that way, well, that’s ok too, but will be better appreciated if you offer us a drink đ
Photo by Chris Barella. Licence: CC BY-NC 2.0.
Beta squadron engage: better bug subscriptions
Published by Matthew Revell in Beta, Bug Tracking
Ever wished you got less bug mail? Or perhaps that you could better control the bug mail that Launchpad sends you?
Recently, Gary and the yellow squad, plus before them the previous Launchpad bugs team, have been working to give you just that: better control of the email that Launchpad sends you about bugs.
The yellow squad are spending the next couple of weeks adding some additional polish to the new bug subscriptions and notifications system. If you’re part of the Launchpad beta testers team, though, you’ve got access to it right now.
So, if you are a Launchpad beta tester, here’s what to look out for when dealing with bug subscriptions:
- You can now choose which events will trigger an email and filter them by types of status, importance, etc., when you subscribe to a series, project or distribution.
- As a result, you can have more than one bug subscription to the same series, project or distribution, each subscription with its own name.
- You can mute individual bugs.
- Bug mail that results from a named subscription has a “X-Launchpad-Subscription” header, and a line in the body of the email, quoting the name you gave the subscription.
- You can see, and edit, all the different ways in which you might receive email about a particular bug by clicking “Edit bug mail” on a bug page.
I’ll announce the feature properly, with a nice fancy screencast and all that jazz, when we release it in full.
If you’ve got any questions, come join us on the launchpad-users list. If you come across any bugs, please report them with the “story-better-bug-notification” and “beta-team” tags.
Anyone can join the Launchpad beta testers team and, unlike Hotel California, you can leave at any time.
Photo by Nils Geylen. Licence: CC BY SA 2.0
Sharing translations
Published by Matthew Revell May 5, 2011 in Cool new stuff, Translations
It’s incredible to think that more than 57,000 people have used Launchpad to translate software from English into their own language.
Many of them have worked directly on upstream projects, such as the OpenShot video editor. Others have helped translate Ubuntu packages of software. And then there’s a whole group of people who translate upstream software outside of Launchpad.
Today we’ve taken another step in bringing those efforts closer together by making it far easier to get upstream translations directly into Ubuntu.
We want the strings produced by translators working directly on software projects, whether in Launchpad or elsewhere, to be easily available to the Ubuntu translators and we believe it should be just as easy for software projects to take advantage of the work of Ubuntu translators.
How it works
Translation sharing between different releases of a project, or Ubuntu, has been available in Launchpad for some time now. Also, sharing translations between an upstream project translated in Launchpad and its Ubuntu package has been helping to bring those two communities of translators closer together.
What’s changed today is that strings from upstream projects who make their translations outside Launchpad are now just as easily imported and ready for use by Ubuntu.
Now, so long as the upstream project is set up in Launchpad to do this, a change made in an upstream project’s source code — whether hosted directly in Launchpad or elsewhere in Bazaar, Git, Subversion of CVS — will be available to Ubuntu translators just a few hours later.
Previously, Ubuntu took translation templates and files from the source packages as they were uploaded. There was no automated route for those new upstream translations to get into Ubuntu after that initial import. In effect, this allowed Ubuntu translations to diverge from upstream during the six month Ubuntu cycle.
This change has a nice side benefit of making it easier for upstream projects to make use of translation work done for Ubuntu, because the English strings will diverge far less and it will be easier to spot where the Ubuntu community has done new translation work, rather than their being a divergence due to the two efforts drifting apart.
To start with, this is available for projects that use intltools, which includes all of GNOME. To get your project’s translations automatically imported into Launchpad, see our help guide.
Photo by Kino Praxis. Licence: CC BY 2.0
What’s next? Part 2: Features
Published by Francis J. Lacoste May 4, 2011 in General
In my last post, I explained how squads doing maintenance picked the next bug to work on. But how does it work for the other squads?
We have two squad that works on a project which is usually a feature. In this context, a feature means something that will take a team of 4-5 engineers several weeks (or months) to develop. It will usually need a good amount of discussion with the stakeholders to clarify requirements and we’ll do user testing along the way.
We maintain a short queue of 2 projects to work on next. The items on the queue are determined through the Stakeholders Meeting process. The stakeholders cabal meets once a month (when there is a free slot on the queue) to discuss what’s should be the next items to be developed by Launchpad feature squads. The way it works is that before the meeting interested parties send in their proposal with justifications as why this is the most important piece. People discuss each other proposals. Then the Launchpad Product Strategist (Jonathan Lange) and I will come back with a proposal taking into account the stakeholders discussion. That proposal is discussed during the meeting and a decision on what to add to the Next queue is taken. We try to operate by consensus, but in the end, the Product Strategist has the final say.
The stakeholders group composition which is made of one representative from the major teams within Canonical derives from the business goal of Launchpad which is to give Canonical a competitive advantage in delivering a high quality OS.
An error that is easily made from that would be to think that only the interests of people within Canonical matter in determining What’s Next? If that would be the case, it would be a very shallow view on our part and we would miss the more general aspect of achieving our business goal which is also to accelerate open-source software development. (Still to give Ubuntu a competitive advantage over proprietary solutions, but hey, it’s a well-known fact that Canonical is a for-profit company.)
The burden of taking into accounts the wide-majority of non-Canonical Launchpad users fall on our Product Strategist’s shoulders. He listens closely to users, in person, on mailing lists, by taking into consideration things reported during user testing sessions. You can always find his long-term plans on the roadmap.
I want something in, who should I talk to?
- If you are within Canonical, talk to the representative working in your unit.
- Otherwise, talk to the product strategist. The easiest way is to start a discussion on the launchpad-users mailing list.
- For Ubuntu folk, we area working with the Ubuntu Technical Board to get a representative who would cater for Ubuntu Project as a whole. But they still haven’t made a decision as to whom they will appoint. Once they are appointed, you should contact them. In the mean-time, talk to the strategist.
Not all features are created equal
Not all feature requests will take several weeks for a squad to implement. For those that can be tackled by one engineer in one or two weeks, they’ll be taken by one of the maintenance squad. These small features can escalated by the stakeholders. (That was the other mechanism by which a bug could be escalated to Critical in my last post.)
When we put items on the Next queue, the feature definition is quite vague. It will specified through a LEP by the product team and the assigned squad once it’s time to work on it. But how that work and what happens after that is probably the topic for another post (as is the answer as to why people write LEPs before we decide to work on the thing).
Hope these posts shed some light on how we decide What’s Next?
Photo by Anonymous. Licence: CC BY 2.0.
How do we determine “What’s next?”
Published by Francis J. Lacoste April 29, 2011 in General
To many people, Launchpad development looks like a black box. People asks for thing in various places (the bug tracker, the mailing lists, IRC, directly to developers, or simply wish it out loud) and then, often unexpectedly, Lauchpad will change.
We strive to work in the open, discussing changes on the development mailing list or on the bug tracker, publishing our Kanban board, announcing stuff here on this blog, often trying to contact concerned users directly. But because Launchpad is a big project catering to the needs of many different type of users, it’s easy to miss out on some people.
So here it is, the Definitive guide on how Launchpad folks decides what to work on next!
Since the squad reorganisation, the principles used to determine what’s next will depend on whether we are looking at a maintenance squad or a feature squad.
What’s next for maintenance?
Let’s start by the easiest case: maintenance. Squads on maintenance works from the bugs in the bug tracker. And then we work on bugs starting from highest importance (Critical currently). Our triage rules explains how we determine bug importance. That’s a very verbose page that in practice means today, treat it as critical if:
- it’s a regression
- it causes an OOPS or a timeout
- creates operational issues
All the other distinctions between High, Medium and Low at this point are moot until we clear the backlog of such issues (see my status post to see how we are doing there). That’s not to say that we don’t fix High, Medium or Low bugs. Developers can, at their discretion, decide to work on such bugs if they happen to work in the area, or they find it related to a critical bug, or just because. But developers on maintenance will be generally found fixing critical bugs at this time.
Which one? We usually try to work on the “hot” ones. Those are the ones happening frequently or recently. But after that, it’s really up to developer’s discretion. They’ll usually pick based on their area of competence or area in which they want to acquire competence.
Once we are done with the Critical backlog, then we’ll tackle High bugs. Again, the same kind of decision process will be used to decide which one to pick next: that is, developer’s discretion. The idea is that time on maintenance rotation should be mostly self-directed for developers.
There is another way that a bug can jump the queue, it can be escalated to Critical importance. Since it’s closely related to the stakeholders’ process, I will cover it in my next post where I’ll discuss on how we determine What’s Next? for feature squads.
Photo by Crystal. Licence: CC BY 2.0.
Launchpad read-only 08.00 UTC 4th May
Published by Francis J. Lacoste in Notifications
Launchpad’s web interface will be read-only, with other aspects offline, for around 90 minutes from 08.00 UTC on the 4th May 2011.
Starts: 08.00 UTC 4th May 2011
Expected to end by: 09.30 UTC 4th May 2011
This is to allow for a structural update to Launchpad’s database.
Ubuntu 11.04
Published by Matthew Revell April 28, 2011 in General
Congratulations to everyone in the Ubuntu community on the successful release of Ubuntu 11.04!
Here’s to the next six months of oneiric fun.
Photo by Sharon Terry. Licence: CC-BY-ND 2.0.
Gufw in Launchpad
Published by Matthew Revell April 26, 2011 in Projects
If you’re an Ubuntu user, it’s likely that you’ve used UFW — the Uncomplicated Firewall — and maybe also its graphical front-end, Gufw.
I spoke to Marcos Costales from Gufw to ask about the project and their use of Launchpad.
Matthew: What prompted you to start the project?
Marcos: In 2008 I was translating and testing, but I wanted to contribute more. When Canonical released ufw, I read some reviews that a firewall using the shell was not an uncomplicated firewall; reviews did not see that ufw was perfect for servers and a base with great ideas for something else, I saw a clear opportunity for the development of an application like Gufw.
Matthew: How many of you are working on it?
Marcos: After the first week following release, Vadim joined the project and we were able to generate a lot of expectation. It was amazing to see how Gufw grew exponentially thanks to the contribution of the community. An important point was Cedrick’s mockup for setting a good interface.
From here I would like to thank Vadim, Emilio, RaĂșl, Planella, RubĂ©n, RogĂ©rio, Cedrick and Devid, Gufw is what it is thanks to them.
We are currently working on an application that really simplifies the task of setting up a firewall: very minimalistic, easy to use and understand.
Matthew: How much connection is there between the Gufw and UFW communities?
Marcos: From Gufw we pay attention to the next ufw versions and we request changes we need. We want to thank Jamie for his effort and interest in all of our requests.
There is also an awesome work of documentation taking place in the Ubuntu Wiki.
Matthew: Does Launchpad help the two projects work together?
Marcos: Yes, we can follow the blueprints of the next ufw version and review which changes could affect Gufw. We can easily reassign ufw and gufw bugs…
Matthew: Why did you choose Launchpad?
Marcos: Gufw started in Google Code. After one month we moved to Launchpad, and it certainly was one of our best decisions because it offers us all necessary services and an amazing integration between them.
Matthew: What’s your favourite Launchpad feature?
Marcos: Translations. I am a translator in external projects to Launchpad, and I must say that the usability and simplicity of Launchpad is unique.
Matthew: What would you most like to see added to Launchpad?
Marcos: Maybe a small space for a custom website. We must use an external hosting for the main project website.
Matthew: What do you think is Launchpad’s biggest weakness?
Marcos: At first Launchpad seems overly complex and big (compared for example with Google Code). One idea would be to have two views according to the needs/experience of the project: the current one and an easier to use one.
Matthew: Are you looking for people to contribute?
Marcos: Of course we are. There are always pending tasks for anyone who wants to help and everyone is welcome.
Matthew: Thanks Marcos!
