How we’re open sourcing Launchpad.
Published by Karl Fogel January 16, 2009 in General
Recently we announced that we’re open sourcing Launchpad, with a self-imposed deadline of 21 July 2009. (22 June 2009 ed. note: we may push the date a bit, for testing purposes; it could be in August instead.)
Behind that announcement is a lot of activity. Obviously we’re not going to just throw the code over the wall and wish everyone good luck. The point of doing this is to bring the community that uses Launchpad.net into the development of Launchpad.net. There’s a philosophical reason for this: for a site whose primary purpose is to enable free software projects to collaborate, it’s natural that the users should be involved in improving the site itself.
But there’s a more practical reason, too.
One of my favorite metrics for judging a project’s success is to watch its bug tracker: the more bugs filed, and the faster the rate of new filings, the more successful the project is.
Those who don’t work in software sometimes express puzzlement at that metric: “What? How can more bugs be better?” But software developers know exactly what I mean: the rate of bug filing is proportional to the number of users, not to the number of actual bugs. (More precisely, it’s proportional to some combination of the number of users and their level of technical sophistication, since certain kinds of users are much more likely to file bugs than others.)
Well, I’ve been watching the Launchpad.net bug tracker for several weeks now, and judging by the bug-filing metric, Launchpad.net is very successful. Great. But what that means in practice is that we can’t resolve the majority of incoming bug reports and feature requests. The Launchpad development team at Canonical simply does not have enough surface area to handle it all. If we doubled — indeed, if we quadrupled — the size of the team, it still wouldn’t be enough. With a site like this, whose user base is large, and growing rapidly, there are really only two options:
- triage mercilessly, and leave most things undone
- open it up and let the users help
Clearly, answer 2 is better.
It implies some preparatory work on our part, however. We’re seeding the ground with developer documentation: this has already begun, though we’re still transferring over much of our internal documentation (remember, we have to go through everything and make sure we don’t accidentally open up any confidential business-related things — all this stuff was written by people who thought it was internal to the company at the time).
We also need to go through our dependencies and make sure we don’t have any license compatibility issues. The license on Launchpad will be the AGPLv3, but we still have to vet dependencies and work out any problems. By definition, this must happen before we release, so it’s work that Canonical must do internally.
Most importantly, we need to move our development discussion forums out into the open. Fortunately, most of Canonical’s Launchpad developers already have plenty of experence working in open source communities: they’re ready for this move, and we’re planning to do it before the code itself is opened (see the schedule), to minimize the number of simultaneous changes. We’ll also be publishing policies on how we’d like the community to work, and on how changes will be accepted back into the mainline and deployed on Launchpad.net. (The short answer is that Canonical decides, of course: we host the site, therefore we are responsible for the software that runs on it. The longer answer is that we want to make it easy for good changes to make it onto the site, and have some concrete plans for how to do that.)
In the near term, the next things you’ll see are more independent modules being opened up: code extracted from Launchpad and made into independent libraries for anyone to use (for example, Storm, LAZR.config, and LAZR.delegates).
And that’s all for now. Watch this space for more.
Pidge!
Published by Matthew Revell January 15, 2009 in Projects
Fergus Ross Ferrier tells us about his project, Pidge.
Matthew: What is the Pidge project?
Fergus: The goal is to have an open web platform — code and data — that students can use as a robust, trusted online community for sharing relevant information across their campus: events, initiatives, courses, peer education … all via their online ‘pidgeon hole’.
The only current installation — codename MyPidge.com, and a separate project on Launchpad — is at the University of Cambridge, England.
I can’t say it’s a raving success at the moment (it’s not), but there’s strong indication that this is a worthwhile goal, and we just need to plough on and improve it to the point where it gets widespread adoption.
Matthew: What parts of Launchpad do you use for Pidge?
Fergus: Mainly code hosting and bug / blueprint tracking at the moment. As soon as someone starts using it in a locale other than the UK, we’ll look at translation, and answers I’ll think about as a primary support method for users.
Matthew: Why did you choose Launchpad?
Fergus: The bits fitted together nicely. Linux, Apple and Django all benefit from the full-stack approach, and I really don’t want to waste my time chasing the ‘best’ software project management tool. I’d simply like to trust people at Canonical to work that out for me.
Matthew: What would you like to see changed in Launchpad?
Fergus: Consumption of OpenID…?
And it’d be super-cool if the UI and workflows were so well tested for non-technical people that I could actually send ordinary users to the Bugs / Blueprints / Answers areas and get them to chip in productively, without them having to work out the whole structure of the project.
Matthew: What do you particularly like about Launchpad?
- Err, it’s free.
- It’s used for a number of high-profile open-source projects (and thus hopefully will continue to be developed and supported!)
- And I really like the open nature of the whole thing: how anybody can walk into any project listed, pick up the structure, and get involved. No politics, no asking for commit access to a repo, no hidden bug trackers.
Matthew: What’s next for Pidge?
Fergus: Well I need to learn a few things about motivating other students (and myself!) and keep ploughing on until it reaches critical mass here at the U of Cambridge.
And, as this is designed as a reusable package, I’d like to see someone at another student campus in the world taking up the gauntlet to set up a remote installation. Referrals, suggestions and introductions welcomed!
What’s new with the Launchpad web service API
Published by Leonard Richardson January 12, 2009 in API, Cool new stuff
The frequency of these posts has fallen off recently because I’ve been working on a Javascript client for the Launchpad web service, which we’ll be using to add some Ajax functionality to Launchpad. But it’s time for another one, featuring progress that’s visible to you.
First, an announcement: on Tuesday, the 20th of January, I’ll be doing an IRC chat on the Launchpad web service as part of Ubuntu Developer Week. See the schedule for details.
Newly published objects
The Bugs team has published CVEs through the web service. There’s a cves collection associated with every bug, and you can link and unlink CVEs from bugs.
The Soyuz team has published archives. You can use the web service to inspect a distribution archive or PPA, copy packages from one archive to another, and manage the permissions of who’s allowed to upload to an archive.
Merge proposals have also been published, but they’re read-only for now, so not very useful yet. But pretty soon you should be able to integrate them into an external code review tool.
Modify fields directly instead of through named operations
Consider the bug task object. Up to this point it’s had a number of read-only fields like ‘status’, ‘importance’, and ‘assignee’. These fields aren’t really read-only: you can modify them, but you have to know the secret. Each has a corresponding named operation: transitionToStatus, transitionToImportance, and transitionToAssignee. To modify ‘status’ you need to invoke transitionToStatus.
So you can’t modify a bug task’s status the way you can modify a bug’s description. This launchpadlib code works:
>>> bug.description = "A new description"
>>> bug.lp_save()
But this code doesn’t (except now, on staging):
>>> task.status = "New"
>>> task.lp_save()
You have to do this instead:
>>> task.transitionToStatus("New")
I’ve long felt that this transitionTo stuff is an internal detail you shouldn’t have to worry about, and judging from the bugs you’re filing, some of you agree. So I’ve made ‘status’, ‘importance’, and ‘assignee’ look like regular read-write fields.
The transitionTo methods are still available, so your old code will still work. In fact, the new code just calls the server-side transitionTo methods behind the scenes. The validation errors you used to get from passing a bad value into transitionToStatus will happen the same way if you set ‘status’ to a bad value.
There are other named operations that could be replaced by making the read-only field they modify into a read-write field, but I only changed those three bug task fields. I’ve talked to other Launchpad programmers about this new tool, and they’ll start using it according to their own schedules.
http_etag
Finally, there’s one part of the Javascript work that’s generally useful if you’re writing code against the web service on the level of HTTP requests rather than using launchpadlib. That’s the http_etag field now associated with entry objects such as people and bugs. It’s the same information provided in the HTTP header “ETag” when you get the entry object. So why send it again?
Well, imagine that you get a whole collection of bugtasks, and then decide you want to edit one of them. Ideally you’d use the value of “ETag” to make a conditional PUT or PATCH request, so that you wouldn’t accidentally overwrite someone else’s changes.
But you never got the ETag for that bugtask, because you got it as part of a collection. The http_etag field comes to the rescue here, allowing you to make a conditional PUT or PATCH without having to send a separate GET just to get the bugtask’s ETag.
Launchpod 15 – Launchpad’s going open source!
Published by Matthew Revell January 9, 2009 in Podcast
Launchpod: the Launchpad team podcast!
Host: Matthew Revell.
Theme: Obscurity by Barry Warsaw.
Launchpad will be open source on the 21st July this year! (22 June 2009 ed. note: we may push the date a bit, for testing purposes; it could be in August instead.)
Karl Fogel joined the Launchpad team recently as the Launchpad Ombudsman. Find out what that unusual job title means and hear Karl talk about the Launchpad team’s plans for going open source, our new development wiki and how we’re planning to build a community process around the newly open source Launchpad.
Day twelve – Loggerhead
Published by Administrator January 7, 2009 in 12 days of Launchpad
Welcome to the last of our Twelve days of Launchpad series. For our final spin, we’ll take a look at an open source project that not only forms an important part of Launchpad but that you can also install locally or on your own server: Loggerhead!
Loggerhead gives you a web interface to Bazaar branches, allowing you to:
- browse a branch’s directory structure
- view files
- see diffs for each revision
- search files in the branch
- get the output of
bzr annotate— crediting each line of code to its author.
You can use Loggerhead to view any branch in Launchpad by clicking the Source code tab on the branch’s overview page. Let’s see it in action on Drizzle’s trunk.
Have a click around and you’ll see that Loggerhead gives you an easy way to navigate a Bazaar branch and explore its history.
Running Loggerhead locally
That’s only part of the Loggerhead story, though, because you can install it on your own machines. You get everything you see on Loggerhead through Launchpad, as well as the ability to browse through all branches on your machine — rather than one branch at a time — plus the option of a beefed-up search.
Right now, Loggerhead is packaged for Debian and also for Ubuntu (in universe for Jaunty and the ~bzr PPA for other Ubuntu versions).
Once you’ve installed the package — see our guide if you’re new to installing from PPAs — open a terminal, visit a directory where you have some Bazaar branches and enter:
$ serve-branches
Then, visit http://localhost:8080. That’s it: you can now browse around and use Loggerhead as a friendly interface to your Bazaar branches.
Get involved
If you have questions about Loggerhead — or you want to contribute — you can find the project on Launchpad and talk to the Loggerhead team using the Bazaar mailing list.
Notification of Launchpad Legal page changes
Published by Joey Stanford January 6, 2009 in General, Notifications
Hi,
Today we have updated the Launchpad Legal page [1] with the following changes:
1) The Dev wiki [2] is now called out explicitly as having a CC content license. Previously the Dev wiki proclaimed it was licensed under CC but was not listed on our Legal page.
2) The Content License section was updated for clarity. This was a housekeeping task and does not effect any Legal changes.
3) Future notifications of legal changes will be sent only to the Launchpad Announcement list [3]. Previously they were sent to the Launchpad Users list and News blog.
Joey
[1] https://help.launchpad.net/Legal
[2] https://dev.launchpad.net/
[3] https://lists.ubuntu.com/mailman/listinfo/Launchpad-announce
Day eleven – try things out on staging
Published by Matthew Revell January 4, 2009 in 12 days of Launchpad
Often, if you’re trying out a new feature — or you want to show someone how to do something — it’s likely you want to use real data but without having a lasting effect.
Launchpad’s staging environment allows you to do just that. Staging’s database is refreshed once each day by making a complete copy of the main Launchpad database. That means you can try things out but you don’t have to worry about spoiling real data or adding lots of useless test data. Within 24 hours, any changes you make on staging are wiped out by a fresh copy of the main Launchpad database. Just make sure you don’t do anything on staging that you want to keep 🙂
One thing to note is that staging runs the very latest code from the Launchpad developers so you may notice bugs from time to time. Of course, if you do spot a bug, please report it.
Day ten – karma
Published by Matthew Revell January 3, 2009 in 12 days of Launchpad
Karma is a shorthand way of showing how active someone is in Launchpad. If you have a Launchpad account then you also have a karma score.
Karma is simple: roughly speaking, the higher someone’s karma score, the more active they are in Launchpad. There are a couple of things to note, though:
- karma decays: something you did six months ago earns you less karma than something you did today
- not all actions are equal: some work earns you more karma than other work.
There’s more about karma in our help guide.
Day nine – copying PPA packages
Published by Matthew Revell January 2, 2009 in 12 days of Launchpad
You can copy packages from other PPAs into any PPA that you can upload to. You also have the option of copying packages between distro-series (i.e different distribution releases).
For example: take a look at the Ubuntu Mobile team’s PPA copy packages page.
Here you can:
- select one or more sources to copy
- select the destination PPA — you must have upload permission for that archive
- specifiy the destination series
- choose whether or not to also copy the related binary package.
As soon as you request the copy, the source will be listed in your PPA with details of its origin. However, it can take up to twenty minutes for the files to actually appear in your archive.
If you copy only the source, the corresponding build records are created in the destination PPA immediately.
Day eight – Launchpad Bugs by email
Published by Matthew Revell January 1, 2009 in 12 days of Launchpad
Happy new year and welcome to the eighth day of Launchpad! Today we’re looking at one of the ways you can use Launchpad without having to fire up a web browser: Launchpad Bugs’ email interface.
Unless you’re totally new to Launchpad Bugs, you’ve already seen one side of the bug tracker’s email interface each time you get a notification about a bug. Before you can start filing bugs and manipulating existing reports by email, you’ll need to register your GPG key with Launchpad. Every email you send to the bug tracker must be from an address registered in Launchpad account and signed using a key that Launchpad knows about.
Okay, so let’s get going. First off, let’s report a new bug by sending an email like this:
To: new@bugs.launchpad.net
Subject: Foobar does X when it should do Y
Body:
Every time I try to do X in Foobar I find it actually does Y.
affects foobar
It’s pretty obvious what’s going on here: the subject in your new bug report’s summary and the body is the body of your bug report. Ah, but what’s that at end of the body?
affects foobar
Launchpad gives you several commands that you can use in the body of the email. They’ll only work, though, if you put a space at the start of the line and you can only use one command per line. In this case, affects foobar tells Launchpad that the bug you’re reporting is to do with the project foobar. If you’re reporting a bug about a distro package — let’s imagine the foobar project has a package in Ubuntu — you’d use the distro name, followed by a forward slash and then the package name:
affects ubuntu/foobar
So, what about existing bug reports? If you’re dealing with one bug at a time, you can either reply to the bug mail Launchpad sends you or send a new mail to bug-number@bugs.launchpad.net. Let’s say that your bug report was assigned number 1234 and you want to add a comment:
To: 1234@bugs.launchpad.net
Subject: Here's a screen shot file
Body:
I've attached a screen shot, if that helps.
The subject is the comment’s summary and the body is the comment itself. The comment says that you’ve attached a screen shot: yep, simply attach a file to your email and Launchpad will attach it to the comment.
There’s much more you can do with the email interface. In fact, pretty much anything you can to do a bug report using Launchpad’s web interface you can also do by email. Changing a bug’s status? Simple, add the line:
status fixreleased
What about assigning a bug to someone?
assignee matthew.revell
Mark a bug as a duplicate of bug 42:
duplicate 42
Target it to a milestone:
milestone 1.2
There’s more: check out our help guide for full details.
