Launchpad in the second half of 2010
Published by Matthew Revell April 19, 2010 in Coming changes, Cool new stuff
Via Planet Launchpad: Launchpad’s Strategist, Jonathan Lange, writes on his blog:
We’re starting to get a picture of what we want to do in the second half of 2010. In particular, lots of people within the team and within Canonical are starting to get fed up with our privacy and permissions model, which is quite patchy. It’s currently tangled up with the way we send emails to people, and we’d love to untangle them.
The Foundations team are already at work making Launchpad faster, and that’s something we want work on even more in the coming months. Derivative distributions – that is, a Linux distribution that extends or customizes another one, generally Ubuntu – have always been a key part of the vision for Launchpad, and they are finally going to get the effort they deserve.
Finally, we want to do whatever we can to make the Ubuntu Software Center rock harder than it does already. Launchpad occupies a special place in the Software Center world, since it can help make it easier to get applications for your desktop and make it easier to develop those applications.
If you’re keen to know what we have planned for Launchpad, you can subscribe to the roadmap page on our dev wiki.
Feature Friday: project announcements
Published by Matthew Revell April 16, 2010 in Feature Friday
Not sure you need a full blog for your project but still want to announce your news?
Launchpad gives you a no-frills way to make project announcements, complete with an Atom feed.
It’s simple to get started: visit your project overview page and click Make announcement in the right-hand column’s Announcements box. There you’ll also find a link to your project’s announcements Atom feed.
Take a look at Sikuli’s announcements as an example:
Any announcement you make will also show up in the universal Launchpad announcements feed.
Links round-up 16th April
Published by Matthew Revell in General
A few links to Launchpad related posts from the past month or so:
- Fixing the bug tracker widget: Curtis Hovey looks at what’s wrong with the way you set a project’s external bug tracker, in Launchpad.
- No project is an island: Curtis again, “I think the best summary of what Launchpad does is that it hosts open source communities.”
- Canonical pays to upgrade Gnome’s Bugzilla: “…the makers of Launchpad paid for improvements to Bugzilla, a competing product—not to mention that Ubuntu’s competitors will benefit from improvements to GNOME. As [Kiko] notes, Canonical views this as ‘bridging the gap’ from Ubuntu to upstream.”
- Microsoft developer Garret Serack announces The Common Opensource Application Publishing Platform (CoApp): “CoApp aims to create a vibrant Open Source ecosystem on Windows by providing the technologies needed to build a complete community-driven Package Management System, along with tools to enable developers to take advantage of features of the Windows platform.” And it’s hosted on Launchpad.
- Being the Launchpad Release Manager: Deryck, the Launchpad Bugs team lead, talks about managing a Launchpad release and asks if it makes sense to talk about website releases.
–fixes lp:1234
Published by Matthew Revell April 9, 2010 in Bug Tracking, Code, Feature Friday
As I’ve said before, Launchpad is pretty big. Getting to know everything you can to do in Launchpad can take a while.
Of course, there are the user guide, the tour and the dev wiki even has a feature check-list. It’s still easy to miss things.
So, I’m turning the fifth day of each week into Feature Friday 🙂
I’m gonna kick off with something I use a lot and that, to be honest, is more a Bazaar feature, than a Launchpad feature:
bzr commit -m "Adds email functionality to the client, thereby obeying Zawinski's law." --fixes lp:1234
Adding --fixes lp:1234 to a commit tells Bazaar that the branch contains a fix for bug 1234 tracked in Launchpad.
The next time you push the branch to Launchpad, Launchpad will create a link between the branch and bug 1234.
How does bug triage work for you?
Published by Matthew Revell April 7, 2010 in Bug Tracking
I want to learn more about how and why people triage bugs, whether that’s in Launchpad or another bug tracker.
So, I’m inviting people who often triage bugs to come to either London or UDS in Brussels to tell me more about their experience.
If we get two or three people somewhere other than London or Brussels, we may also be able to come to you.
All I need is around an hour of your time where, along with my colleague Charline, I’ll ask you to show me how you triage bugs. If you’re interested, or have questions about how it works, mail me: matthew DOT revell AT canonical DOT com
Launchpad read-only 11.00-13.00 UTC 31st March 2010
Published by Matthew Revell March 26, 2010 in Notifications
We’re releasing the latest version of Launchpad on the 31st March. While we roll-out the new code, Launchpad’s web interface will be read-only and other services, such as code hosting and PPAs, will be unavailable.
Starts: 11.00 UTC 31st March 2010
Expected back by: 13.00 UTC 31st March 2010
We’ll post details of the new release right here.
Launchpad’s Bug Watch system and other animals
Published by Gavin Panella March 19, 2010 in Bug Tracking
Launchpad has a feature where it periodically checks the status of remote bugs (as in, bugs recorded in another bug tracker, like bug 12720 in Django).
When someone links a bug on Launchpad with a remote bug it’s called a bug watch. All the bug watches for a bug appear in the Launchpad bug page in an area called “Remote bug watches”. Check out bug 513719 to see a bug watch for bug 12720 in Django.
If the remote bug tracker has been set as the bug tracker for a project in Launchpad, bug tasks for that project can be linked to a specific remote bug too. When the status of the remote bug changes, Launchpad changes the status of the bug task to match, and sends out email to subscribers, the same as if the status had been changed in Launchpad. See the Django bug task in bug 513719 for an example.
Going further, comments can be synchronized too, in both directions. Recent versions of Bugzilla have this capability built in, but older versions can be supported with a plugin. There’s also a plugin for Trac.
This is all very nifty stuff, but it suffers because it doesn’t work very well! Yet.
Read the rest of this entry »
Getting started with launchpadlib: Launchpad’s Python library
Published by Matthew Revell March 11, 2010 in API
Launchpad’s strategist, Jonathan Lange, has started a series of blog posts on getting started with Launchpad’s Python library, launchpadlib:
launchpadlib is the Python client-side library that talks to Launchpad’s own REST API. It turns out that customize scripted control of a bug-tracker-code-hosting-translation-distribution-building-cross-project-collaboration thing is actually quite handy.
Catch-up with the first two posts in the series:
And you can subscribe to Jonathan’s blog or follow blogs from both Jonathan and other members of the Launchpad community on Planet Launchpad.
Merge proposals: improved comment handling
Published by Matthew Revell March 4, 2010 in Code
Tim has made a couple of improvements to the way that comments are displayed on merge proposals.
The first is pretty simple but makes it far easier to see which merge proposals need attention. Up until now, if you gave your merge proposal a description it would show up as a comment. This made it harder to see which merge proposals had zero activity.
Now, your description no longer shows up as a comment. And you can edit your description in-line using the same Javascript editor as you’ll find on bug pages.
The other change affects merge proposals that supersede another merge proposal. The merge proposal page explicitly states that it supersedes a previous proposal.
It also lists all the comments from that previous review, giving them a yellow background and a link to the superseded review so you can easily tell them apart from comments on the current review.
You can’t be too helpful: Better handling of large blobs by +filebug
Published by Graham Binns in Bug Tracking
Imagine the scene, dear reader. You’re running the latest Ubuntu pre-release, dilligently testing that everything works the way it ought. An application crashes horribly; Apport pops up to tell you that it spotted the crash – would you like to report a bug?
“Of course I would,” you cry, “I am a desktop testing hero!” And so Apport does its thing and takes you to Launchpad to file the bug report. And then Launchpad times out.
At this point, if you’re like me, you might shout a bit. You refresh and refresh with all your might but still Launchpad will only give you an error page. Finally, defeated, broken, you close your browser and shuffle off into the corner of your room, where you bury yourself under the mountain of discarded CD-Rs that contain daily ISOs of Ubuntus past and sob into your coffee.
Okay, so maybe I’ve exaggerated it a bit, but that doesn’t change the basic fact that timeouts on the +filebug page when you’re filing a bug via Apport are intensely, soul-destroyingly annoying. They’re annoying to us in the Launchpad Bugs team too, because we see them in our error reports. They’re so annoying, dear reader, that we’re moved to hyperbole when writing about them for the official Launchpad blog.
The problem with processing data supplied by Apport has always been one of scale. Originally the extra data that Apport would upload to Launchpad wouldn’t be massive, maybe hitting 10MB if the application was particularly busy. Because of this, Launchpad simply processed those data synchronously whilst loading the bug-filing form for you, so that the data you’d uploaded would be included with the bug.
Of course, that approach doesn’t scale very well, and recently we’ve been seeing the data blobs that Apport uploads hit ~100MB in size. That’s far too big for Launchpad to handle in a timely manner whilst doing all the additional work of rendering the bug filing form for you, so in those circumstances it invariably times out and you get that ever-annoying error page.
This was an interesting problem to solve, and we came up with a number of different possible solutions. One viable solution for this, which we eventually decided not to implement, involved having a separate request for processing the extra bug data and then loading the data into the filebug form with AJAX. We discarded that idea because there was always the chance that that request would time out, leaving us in an only slightly better position than we were already.
There was some discussion on the Launchpad developers mailing list about whether we could just defer loading the extra data into the bug until after it had been filed, but we quickly realised that not only could the extra data carry an initial subject for the bug, but it could also indicate that the bug should be filed as private, something which currently can’t be done via the Launchpad web UI.
The solution we chose to implement, which we’ve now rolled out to the Launchpad edge and production servers, is to have a queue of blobs waiting to be processed. We already have quite a robust job-processing system built into the Launchpad codebase, which we use for creating the diffs in merge proposals and calculating bug heat, amongst other things. Adding support for processing uploaded blobs was quite simple, since the existing blob parsing code was well documented. The blob processing jobs are picked up and run by a cron script that runs every minute or so, and the data retrieved from the blobs are stored with the original processing job as a JSON-formatted string. When you hit the +filebug page it checks to see if the relevant blob has been processed. If not, it waits until processing is complete. Once processing is complete the serialized data are loaded into the +filebug page for use later on.
The advantage to you as a user, then, is that you should never again see a timeout on the +filebug page due to the size of the blob that Apport has uploaded. With the upcoming release of Ubuntu Lucid, we’re hopeful that this will make a real difference to those people testing the pre-release versions of the distro.
