Nikki and the Robots
Published by Matthew Revell May 19, 2011 in Projects
Nikki and the Robots is the first game from Berlin based games studio Joyride Labs. It’s a retro-styled platformer with beautiful colours and an open source licence, with bugs tracked in Launchpad.
I asked Iwan & Sönke from Joyride Labs about the game.
Matthew: Nikki and the Robots is LGPL and Creative Commons licensed. What made you choose open source licences?
Iwan & Sönke: This one is easy! Our love of open source software and free art made us do it! Also we expect that being open will get us additional attention and love.
Our work and how we license it is an experiment too, so actually we ‘hope’ rather than expect. 🙂
Matthew: How are you planning to distribute the game once it’s ready?
Iwan & Sönke: We are working on the first part of Nikki and the Robots and will start in-dev-sales (pre-sale) once it is ready.
Game, editor and user levels will be free as in freedom. A part-proprietary organic story mode with enhanced levels and additional in-game-art will be available for pay.
Matthew: Can you tell me a bit more about the technology behind the game and the decisions you made? I see, for example, you’re using Haskell.
Iwan & Sönke: Haskell is just my (Sönke’s) favourite language. I have the impression that I can do coding in Haskell much faster than in other languages and I produce less bugs. Besides Haskell we use Qt and OpenGL as the graphics backend and Chipmunk as the physics engine. By the way: we completely rely on free software for compilation on all platforms (so, no VisualStudio or XCode, just gcc, cmake, mingw32, etc.).
Matthew: How are you finding Launchpad as a bug tracker?
Iwan & Sönke: It’s quite usable. Forum and wiki might be useful features to consider for the platform. (We use a free wiki system and will probably set up an own forum soon).
Matthew: Thanks to Iwan and Sönke. You can download an alpha of Nikki and the Robots from the Joyride Labs website.
How we triage Launchpad bugs
Published by Matthew Revell May 17, 2011 in Bug Tracking
If you’ve ever wondered why a particular bug report about the Launchpad project is marked as Low, High or Critical, you should read our bug triage guidelines.
Okay, so, if you’re not directly involved with triaging Launchpad bugs then that may not be the world’s most compelling invitation.
So, here’s the short version: we use only the Critical, High and Low importances. We give each a particular meaning:
- Critical: Bugs that should be fixed before other bugs. Ideally, we’d have nothing here.
- High: Bugs we think we can fix in the next six months.
- Low: Everything else.
That last one can make it appear that we don’t care about your bug but that’s not the case. The reason we use Low is to avoid setting any unrealistic expectations about when someone in the Canonical Launchpad team will get to that bug. That’s not to say we’d complain if someone else fixed that bug. Also, we’re open to persuasion: tell us why we should increase the priority of a bug you care about.
There’s more in our bug triage guidelines, including what we consider to be a Critical bug.
Photo by Mr. T in DC. Licence: CC BY ND 2.0
A cream pie in the face
Published by Jonathan Lange May 16, 2011 in General
Launchpad has a lot of <a
Launchpad has a lot of critical bugs. A month ago, we had close to 300 of them. At the time of writing, we have 226.
Francis reckons that we can have zero critical bugs by June 27th but I am a little bit sceptical. To that end, I’ve made a wager with the Launchpad developer community:
If we have zero critical bugs by June 27th, then I’ll let one Launchpad contributor shove a cream pie in my face at our next get-together in Dublin.
Here are the ground rules:
- launchpad-project, not launchpad
- The bugs have to be actually closed, and if fixed, actually released
- “Critical” is as defined on our bug triage page (and no cheating by changing the policy)
- Any bugs that are escalated by Canonical stakeholders after the announcement do not count, but any new timeouts, oopses and so forth do count
- I will leave it to others to nominate a pie-er
- A custard pie would also be acceptable
If you want to see me publicly and deliciously embarrassed in the tastiest way possible, then now is the time to start fixing bugs. I will make sure that the event is filmed, photographed, instagrammed, live-tweeted and made available in whatever ways the cool kids are mainlining their microtainment these days.
Since announcing this on Twitter, Ted Gould and Neil J. Patel have also volunteered to be cream-pied if we meet this goal.
Photo by little blue hen. Licence: CC BY 2.0.
Launchpad Answers is faster
Published by Curtis Hovey May 12, 2011 in Answers, Performance
Users of Launchpad Answers will see that asking a question, editing it, or posting a comment to it is faster. Email about question changes is sent a few minutes latter. Many bugs relating to question emails were fixed as we moved the work of sending emails to the new process.
Users and answer contacts saw slow pages or time out errors when working with questions in large projects. Simple actions like asking a question or providing an answer would fail. It was common to see errors converting bugs into questions. A few weeks ago, we saw that 8 of the top 10 kinds of time outs involved questions; though this ratio was caused in part by the tremendous work of making other parts of Launchpad faster.
The root cause of the slow question pages was sending email to all the subscribers before showing the next page. The solution was to queue the the event to notify subscribers, and send the emails later. While updating the code, there were many opportunities to fix related Answers bugs. I am particularly pleased with the changes to the rules to create a question. There were four lines of code, and while I intended to fix one line, I realised there was a bug related to each line of code. In a matter of minutes I had fixed four bugs. The most obvious change you will see is that question emails will now state that you received the email because you asked the question, where previously you were merely described as a subscriber.
Beer as in beer
Published by Matthew Revell in Projects
There’s quite a bit of overlap between home beer brewing and hacking. Both usually involve experimentation, sharing and a love of what you’re doing.
It’s not surprising, then, that there’s more than one open source project aimed at helping home brewers to create the beer they want. A few home brewing projects are hosted on Launchpad, including JolieBulle (that’s French for “pretty bubble”).
Pierre Tavares started the project last year to support his own brewing. The result is an application that helps at every stage of the process. When you’re ready to get going, it helps formulate the recipe and allows for the sharing of recipes using the common BeerXML standard. It helps calculate what brewers call the beer’s profile (its bitterness, colour, how much alcohol it has), includes an ingredients database and has tools that help during the brewing process itself.
I emailed Pierre to ask about the development of JolieBulle. Here’s what he said:
From a technical point of view, JolieBulle is developped in pyQt and integrates well in both KDE and Gnome desktops.
I chose Launchpad mainly for the openness of the platform, and the great tools to manage code, bugs and blueprints. I’m pretty new to DVCSes but Bazaar seems fine, and I have no problem using it. I don’t use the translation tool, as I prefer Qt Linguist.
JolieBulle isn’t yet packaged for any distros and Pierre hopes to attract contributors who can help with that.
Photo by Sizbut. Licence CC BY 2.0.
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
