Author Archive

A cream pie in the face

Monday, May 16th, 2011
4345671678_302dd39c5cLaunchpad has a lot of <a
href=”https://bugs.launchpad.net/launchpad-project/+bugs?field.importance=Critical”>critical
bugs</a>.  A month ago, we had close to 300 of them.  As of the time of
writing, we have 237.
Francis reckons that we can have zero critical bugs by June 27th.  I am a
little bit more sceptical.  To that end, I’ve make 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 get-together in Dublin.
Since announcing this on Twitter, Ted Gould and Neil Patel have also
volunteered to be cream-pied if we meet this goals.
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 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 or whatever it is that the
cool kids are doing these days.

Pie

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.

Get an overview of what we’re doing

Monday, February 21st, 2011

Ever wanted to know what exactly is happening in Launchpad development, but found our list of in-progress bugs too daunting and detailed? Well, do we have a link and a screenshot for you.

Screenshot:

Launchpad Overview Kanban

Link. (Log in: guest@launchpad.net; Password: launchpad).

Thanks to the nice folk at LeanKit Kanban, we’ve now got a guest account set up so that anyone can our kanban board. The board shows all of the high level features that we are working on (those are the green ones), the infrastructure projects we’re doing (those are the blue ones) and all of the community-driven work that we know about (the yellow ones).

The further to the right a card is, the closer it is to being done. The cards in the Next column are the things we’ll start to work on once we’ve got room on the board to start them. “UA” means we’re fixing the final few bugs in a feature before we consider it to be done, and “Deployment” means that we need sysadmins to do something.

Our goal is to keep the amount of work-in-progress down to a small number, and to be able to move things from left to right as quickly as possible. We hope making the board available gives you a better insight into Launchpad development, and maybe even encourages you to join in the fun.

Update: We’ve fixed the log-in credentials, for real this time. Sorry for publishing the wrong ones previously, and previously before that.

Code hosting offline 12.00-12.20 UTC 26th January 2011

Tuesday, January 25th, 2011

Launchpad code hosting will be offline between 12.00 and 12.20 UTC for hardware maintenance on Wednesday, January 26. That’s tomorrow. This means you will be unable to push to, pull from or browse code hosted on Launchpad. All other Launchpad services will be unaffected.

Offline: 12.00 UTC 26th January 2011
Expected back by: 12.20 UTC 26th January 2011

We’ll update this post and our status feeds as soon as we’re back online.

On Friday, our codehosting server went offline unexpectedly. Turns out this was due to a hardware failure. Tomorrow, we will be fixing the underlying hardware problem, but that will mean more downtime. Sorry.

Update: The hardware upgrade went well, code hosting is back online.

ACTION: Back up old sources from PPAs

Tuesday, January 26th, 2010

Now that I have your attention…

We’ve been overwhelmed by the popularity of PPAs on Launchpad. In fact, according to our sysadmins, they are a little too popular and now our disks are full.

Full disks mean no more PPAs, and no more uploads to PPAs. We’d like to add some more disks, but we can’t actually do that soon enough for a bunch of complicated reasons.

Instead, we’ve decided that we’re going to remove all of the source files for any uploads that are:

  • in PPAs
  • not published, that is, deleted or superseded
  • have been not published for over seven days

Note that we already delete the binaries for such uploads.

We are going to delete these old files this Wednesday, January 27th. We’re really sorry that we are announcing it so close to the actual event — we know it’s a hassle.

If you want to keep any of these files, you are going to have to download them right now. Here’s how to do it.

  1. Go to your PPA’s web page on Launchpad and click on “View package details”.
  2. Change the filter to search for “Any status”. Click “Filter”.
  3. For each superseded or deleted upload with files you want to save, expand the upload and manually save all the files under the “Package files” heading.

If it’s a busy PPA like the example one, then there will be a lot of old versions to download. If you aren’t sure, you probably won’t need all of them. Ask on #launchpad on Freenode or the launchpad-users mailing list if you are unsure.

The Road Ahead

Friday, January 8th, 2010

It’s my pleasure to introduce to you the single greatest Launchpad planning achievement for 2010: the roadmap.

For the last few months we’ve been working on bridging the gap between the Ubuntu distribution and the upstreams that it’s made from: making it easier for patches, translations, and bug reports to flow between Ubuntu users, Ubuntu developers, and upstream developers.

We’ve been asking users what they want and trying really hard to listen to them. And, of course, since we’re Free Software now, all of our discussion, development and planning is out in the open.

Still, there are a lot of people who care a lot about Launchpad but don’t have time to follow our mailing list or dev wiki. In particular, Ubuntu contributors are generally way too busy making Ubuntu better to keep up with every thread there. If people who care about Launchpad can’t keep track of what we are doing, they can’t tell us how we can do it better, and they can’t cheer us on when we’re doing it right.

We needed something to keep everyone in the loop. But it needed to be something simple, since we don’t want to spend all of our time telling people what we are going to do instead of actually doing it.

At Kiko’s urgings (perhaps inspired by Jono Bacon’s roadmaps), we’ve prepared a roadmap for the next few months of Launchpad development, in which the highlights are:

  • Guiding developers to the most important (hottest) bugs
  • Getting patches attached to bugs into the code review system
  • Automatic imports into bzr from hg (we already do git)
  • Ubuntu packages built fresh each day from the latest code

And of course, there’s more on the roadmap.

We intend to keep the page up-to-date and to keep the URL constant. This means that any time you want to know what we’re planning, you can look at that page and know for sure.

Remember, it’s an expression of intent, and not an actual commitment. If we can figure out a way to better connect the world of open source software, we’ll change the roadmap in a heartbeat.

For those who aren’t content with a high-level overview, you can also look at the 10.5 series on Bugs, Soyuz, Code and so forth. See the page for our current development cycle for a full listing. And, of course, you can keep following this blog for major announcements and items of interest.

I hope you enjoy the Launchpad roadmap, and I can’t wait to hear back from you. Have a great 2010.

Launchpad: The next six months

Wednesday, October 21st, 2009

A couple of weeks ago, the Launchpad team leads at Canonical gathered in Millbank Tower to talk about what we’ll be doing over the next six months. We talked with each other, we talked with Martin Pool from Bazaar, we talked with people on the Ubuntu Platform team, we talked with Mark Shuttleworth, we talked a lot.

Over the week, two very important things slowly began to dawn on us. I’ll talk about one of them now, and leave the other one to hang tantalizingly in the air like some forbidden fruit that’s learned how to hover.

The first important thing we realized is that Launchpad was originally conceived as a way of helping better connect the Ubuntu operating system to the upstream projects on which it depends. We further realized that could do that much better than we are right now.

A flood of bugs

Zillions of bugs get filed against Ubuntu every day. While some of them are introduced when the Ubuntu community packages software, many are really bugs in the underlying upstream code.[citation needed] And quite often they’re already fixed in the latest upstream version — it’s just that the Ubuntu package doesn’t have the fix yet.

Yet even though Ubuntu is drowning in this sea of bugs, it can’t simply forward them upstream indiscriminately. Upstreams shouldn’t be bothered with old bugs; they only want to hear about bugs that are still in their code. And Ubuntu needs to know when such a bug has been found, both to tell users that a fix is coming and to help plan packaging updates.

Package of the day

Launchpad should be doing much more to help rescue Ubuntu from this deluge. With PPAs and source package branches, Launchpad ought to be able to make it really easy to create a packaged version of the tip of any upstream, to test against, and to file bugs and provide patches directly to that upstream. That is,
Launchpad needs to make Ubuntu Daily Builds rock.

That’s going to be our overall focus now. At the same time, we’re also aware that we need to spend time polishing what we already have. So, for this month and for UDS, we’re going to be focusing only on reducing technical debt, fixing OOPSes and cleaning up the UI.

Where to now?

The Canonical Launchpad team are going to be focused on “bridging the gap” between Ubuntu and its upstreams. We’ll focus on better, faster bug triage, on making it really easy to get upstream tip on the Ubuntu desktop and really tight translations integration between Ubuntu & its upstreams. Early next week, we’ll email out a high-level roadmap of where we want to go.

We are interested in getting real-user feedback about our solution to better integrating upstreams and Ubuntu developers. If you are an upstream or Ubuntu developer interested by that problem, please contact us.

PS. If you’ve read this far, you are probably wondering what the second Very Important Thing was. I’m afraid you’ll just have to wait.

Git imports

Wednesday, July 8th, 2009

As you might have heard already, Launchpad can now import code from Git repositories. You can then create Bazaar branches of those Git repos.

For example:

bzr branch lp:git

Thanks to Jelmer for bzr-git and Michael & Paul for tying it into our rock-solid import system.