Author Archive

Meet Martin Packman in the Blue squad

Thursday, July 5th, 2012

Martin Packman

Laura:  What do you do on the Launchpad team?
Martin:  I’m on the newly created Blue squad, and we’re on the nebulous task of maintenance at present. I’m also on loan doing some juju development work.

Laura: Can we see something that you’ve worked on?
Martin:  You can see everything I’ve worked on. Well, all the things where I’ve had the convenience of using launchpad rather than having to send patches by email.

Laura: Where do you work?
Martin:  From home like most of the other developers in Canonical. I’m only a few hours away from the London office, but haven’t been there since the relocation.

Laura: What can you see from your office window?
Martin:  A weeping birch, and whatever feathered things perch atop. Sky, often blue, generally grey. Houses on the other side of the road. This time of year, swift acrobatics.

Laura:  What did you do before working on the Launchpad team?
Martin:   Bazaar! Which is still a pretty key part of how Launchpad works. In between I worked on a cloud api proxy, which has sensibly been dropped in favour of just using the native openstack api.

Laura:  What did you do before working at Canonical?
Martin:  Whatever came up, computer support and some development work.

Laura: How did you get into free software?
Martin:  Mostly from using it, having it break horribly, and getting the urge to make the code actually work.

Laura:  What’s more important? Principle or pragmatism?
Martin:  Principle is more important, otherwise you compromise all the way to  the other side. But you need some pragmatism to get anything done at all.

Laura: Do you/have you contribute(d) to any free software projects?
Martin:  I’ve tended to submit changes for anything I use heavily at the time, and to various bzr related projects. I’d use this space to hector some maintainer who’d been sitting on a patch for ages, but everyone’s been organised of late.

Laura:  Tell us something really cool about Launchpad that not enough people know about.
Martin:  It actually works pretty well in lynx!

Laura:  Is there anything in particular that you want to change in Launchpad?
Martin:  You mean apart from making it work better in lynx? I’d like bug search to suck less.

Meet Vincent Ladeuil who works in the Blue Squad on Launchpad

Tuesday, July 3rd, 2012

Vincent

Laura:  What do you do on the Launchpad team?
Vincent: Maintenance. Although I’m eagerly waiting for the sprint with gmb to get some hints on how to handle the beast 🙂  In the mean time, I’m focusing on fixing bugs and making the udd importer more testable.

Laura: Can we see something that you’ve worked on?
Vincent:  https://launchpad.net/bzr  and http://babune.ladeuil.net:24842/

Laura: Where do you work?
Vincent:  At home

Laura: What can you see from your office window? View from where I sit
Vincent: The venerable Strasbourg post office, lovely old stones.

Laura:  What did you do before working on the Launchpad team?
Vincent:  Developing bzr.

Laura:  What did you do before working at Canonical?
Vincent:Various service/consulting work for > 20 years, including some episodes at software editors.

Laura: How did you get into free software?
Vincent:  With pleasure

I think the most important event was in 1993: I encountered a blocking bug in g++ related to C++ templates (way before it was standardized). That was a roadblock, no work-around and it was Friday afternoon. In despair, I posted a reproducing case in the related newsgroup. When I came back to work on Monday I got an email telling me the bug was known *and* fixed *and* where to get the patch for the compiler.

That was a light-bulb instant: free software support could be far superior to commercial software support !

One week later, I got a second email asking me if I was out of trouble… Amazing, not only did I get a fix faster than I could have dreamed, but the guy *came back* to ensure I got it…

I never looked back.

Laura:  What’s more important? Principle or pragmatism?
Vincent:  Both are important. If you forget one, be prepared to pay the cost. Both are dangerous too if you forget the other:

– being pragmatic only most often means you’re adding to your tech debt or rely on others to finish your work,

– respecting principles excessively means you never deliver anything.

Laura: Do you/have you contribute(d) to any free software projects?
Vincent: bzr is my most important contributions (including a few plugins). I’ve occasionally sent patches to gtk, perl modules and various other bzr upstream projects.

Laura:  Tell us something really cool about Launchpad that not enough people know about.
Vincent:  Pass  🙂

Laura:  Is there anything in particular that you want to change in Launchpad?
Vincent:  Make it easier to test against for all projects that rely on it (I’m probably biased here as the udd importer severely suffer from not being able to properly test interactions with launchpad (read *and* write (branch creation mainly)).

Meet Jelmer Vernooij of the blue squad

Friday, June 29th, 2012

Laura: What do you do on the Launchpad team?
Jelmer: I’m one of the blue haired freaks on the Launchpad blue squad, although my hair isn’t actually blue – I’m sure we can fix this at the next squad sprint. At the moment, we are working on maintenance: fixing
critical bugs in Launchpad and dealing with incidents.

Laura: Can we see something that you’ve worked on?
Jelmer: I’ve contributed quite a bit to the code behind recipe builds. Most of my work has been on the backend though, not directly user-visible.

Laura: Where do you work?
Jelmer: Like most of us I work at home, which in my case is in Utrecht, the Netherlands. Occasionally I cowork with other teleworkers in Utrecht.

Laura: What can you see from your office window?
Jelmer: At the moment, I see just a big sad drapery made out of rain. On brighter days, I look out on a park and a canal.

Laura: What did you do before working on the Launchpad team?
Jelmer: The Blue squad, which I’m currently in, was originally the Bazaar team. Before that, I worked on the Launchpad team too. This was back in the days when there were no squads, but teams – I was in the Soyuz team. The inimitable Matt Revell interviewed me back in 2010:

Laura: How did you get into free software?
Jelmer: A long time ago, in high school, I ended up maintaining a few server machines running FreeBSD and Samba. After hitting some bugs, a dive into the source code followed to see what I could fix. I’ve been involved with various free software projects ever since.

Laura: What’s more important? Principle or pragmatism?
Jelmer: Do I really have to choose? That’s not very pragmatic.

Laura: Do you/have you contribute(d) to any free software projects?
Jelmer: Beside Launchpad, the main free software project I am involved in is Samba. There are several other projects that I have made major contributions to, such as Bazaar, CUPS, Wireshark, OpenChange, BitlBee.

I’m a Debian maintainer and Ubuntu uploader, mostly for projects I am involved in upstream. This knowledge comes in handy when working on the archive side of Launchpad.

Laura: Tell us something really cool about Launchpad that not enough people know about.
Jelmer: https://launchpad.net/builders lists all the Launchpad builders and
the mischief they are up to.

Laura: Is there anything in particular that you want to change in Launchpad?
Jelmer: It would still be really nice to have dashboards of some kind in
Launchpad. There is even a LEP.

Meet John Meinel – Blue Squad leader and Papa Smurf

Wednesday, June 20th, 2012

Papa Smurf

Laura: What do you do on the Launchpad team?
John: I’m the team lead for the Blue squad. Right now our squad is on Maintenance, so I generally do the coordination work of our team with other teams and the system administrators.

Laura: Can we see something that you’ve worked on?
John: Before we switched to maintenance, our team was focusing on doing Bazaar work. Within the more recent time, we’ve done stuff like fixing up the Ubuntu Distributed Development package importer, and getting translations for Quantal started for Launchpad.

Laura:Where do you work?
John: I work from home in the Netherlands.

Laura: What can you see from your office window?
John: We have a forest near our house, and some of the other neighbors houses.

Laura: What did you do before working on the Launchpad team?
John: As mentioned, we were focused on development of Bazaar, though arguably that was still part of the Launchpad group (not officially, but in spirit).

Laura: What did you do before working at Canonical?
John: I worked for a company developing medical imaging algorithms, mostly for detection and visualization of disease.

Laura: How did you get into free software?
John: Our team wanted to use something better than CVS for development. At the time SVN was pretty hard to set up, and there was just the beginnings of a couple of tools for distributed version control. I got into tla at the beginning, and was happy when Canonical started Bazaar, and I was able to hack on it.

Laura: What’s more important? Principle or pragmatism?
John: I’m a fairly pragmatic engineer. I think it is good to use principle as a guideline, but in the end if the work isn’t in the hands of people using it, it is providing no benefit and is arguably wasted effort.

Laura: Do you/have you contribute(d) to any free software projects?
John: Well, Launchpad and Bazaar are both pretty clear things (and tla a little bit before that). I also developed some other tools while here at Canonical. Such as Meliae for profiling python memory.

Laura: Tell us something really cool about Launchpad that not enough people know about.
John: The UDD package importer turns the changes from debian packages into real VCS branches that you can do lots of nice stuff on. (annotate the history, log the history, see the graph over time, etc.)

I think we are at about 90% coverage, and you can do “bzr log ubuntu:package” to find out the recent history for a package in ubuntu.

Laura: Is there anything in particular that you want to change in Launchpad?
John: My own personal project with launchpad is improving the connection handling when accessing Bazaar branches. Right now it is approximately 3s just to do the ssh handshake and start talking to codehosting. I have some improvements that should decrease that significantly, but we encounter some strange hanging bugs that are only reproducible in production. And LP’s commitment to having minimal user-visible downtime is particularly problematic for SSH connections. A single HTTP request is less than 5s, but an SSH connection can legitimately be active for an hour if accessing a large project.

Launchpad Clinic at UDS-Q

Monday, April 30th, 2012

Let’s face it. Launchpad is not without its bugs. Everyone probably has at least one that they’d like to see fixed, and most of those that do also have the ability to fix them, if only they could get a leg-up on the learning curve of Launchpad development.

To that end, Graham Binns and I will be running two Launchpad Development Clinics at UDS-Q. We’ll be there to help you get on the road to getting your bugs fixed, and to offer advice on every step of the Launchpad development process. We’ll have EC2 instances ready for you to develop on, so if you haven’t already gone through the process of setting up local Launchpad development on your machine, you don’t need to worry.

I have created a wiki page on which you should register if you’re going to be attending either of the clinics. Just list your name and the ID of the bug(s) you want to work on on that page. We’ll check the bugs out and get in touch with you if we think they’re too big to work on in the clinics – in which case we’ll try and work with you to get them fixed over a longer period. We’ve added the event to summit schedule, for Tuesday and Thursday of UDS so why not sign up and come along!

I’m looking forward to hearing from you all, and to helping you make Launchpad awesome(r).

code blue

Contributing to Launchpad

Thursday, April 26th, 2012

Ever wished there was just one feature you’d like to see enabled in Launchpad. Ever wondered when one of the bugs you have taken the time to report and document would be implemented.  Well how about we help you to get these bugs fixed.  Launchpad is a free and open source project, its platform is also open and developed in a transparent fashion. The source code for every feature, change and enhancement can be obtained and reviewed.

This means you can actively get involved in improving it and the community of Ubuntu platform developers is always interested in helping peers getting started. The Launchpad development team are continuously working on areas in Launchpad and other projects but there just isn’t enough time in the day to get every bug fixed, tested, deployed and out there.  What we’d like to help to do is encourage and help users get more involved. We would like to get more of the developer community involved in Launchpad, users who’ve never developed before to experienced hands on developers and show you how to get started. There is documentation written up, but we’re going to explain it a less scary way in  basic steps.

Getting Started

First things first, you need bzr. All of Launchpad’s branches use bzr for source control, so you’ll need to install it using apt-get:

 $ apt-get install bzr

Next, you need to create a space in which to do your development work. We’ll call it ~/launchpad, but you can put it pretty much anywhere you like on your system.

$ mkdir ~/launchpad

Because getting all the ducks in a row to make it possible to do Launchpad work takes a while, we’ve actually got a script that does all the legwork for you. It’s called rocketfuel-setup (see what we did there?) and once you’ve got bzr installed, you can

$ cd ~/launchpad
$ bzr --no-plugins cat http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities/rocketfuel-setup > rocketfuel-setup
$ chmod a+x rocketfuel-setup
$ ./rocketfuel-setup

You’ll be prompted for various details, such as your Launchpad username, and you’ll be asked for your password so that rocketfuel-setup can install all the packages that Launchpad needs. After this, you might as well go and have a sandwich, because downloading and building the source code will take at least 40 minutes on a first run.

Once rocketfuel-setup has completed on your machine, your ~launchpad directory will look something like this:

$ ls ~/launchpad/
lp-branches lp-sourcedeps rocketfuel-setup

The only directory you need to worry about in there for now is lp-branches. As the name suggests, this is where your Launchpad branches are stored.

Now that you’re all set up, it’s time to find a bug to fix and get some coding done!

Where to Begin

Now, it’s fair to say that there are plenty of bugs in Launchpad worth fixing. However, it’s even fairer to say that you don’t want to pick on of the Critical bugs as your first effort for Launchpad development, mostly because the Critical bugs are all fairly complex.

Luckily, the Launchpad team maintains a list of trivial bugs – the ones with simple, one-or-two line fixes that we just haven’t been able to get around to yet. You can find it here on Launchpad.

Once you’ve found a bug you want to fix, you need to create a branch for it. There are some utility scripts to make your life a bit easier here. In this case, rocketfuel-branch, which creates a new Launchpad branch from the devel branch that rocketfuel-setup created.

$ rocketfuel-branch my-branch-for-bug-12345

You’ll now find that branch in ~launchpad/lp-branches

$ ls ~/launchpad/lp-branches
devel my-branch-for-bug-12345
$ cd ~/launchpad/lp-branches/my-branch-for-bug-12345

Now that you’ve got a branch to work in, you can start hacking! Before you do, though, you should talk to someone in #launchpad-dev on Freenode about the problem you’re trying to solve. They will help you figure out how best to solve the problem and how best to write tests for your solution. We call this the “pre-implementation call” (though it can happen on IRC) and it’s very important, especially for first time contributors.

Once you’ve had your pre-imp call, you can get coding. Don’t forget that the people in #launchpad-dev are there to help you as you go. Don’t worry if you get stuck; Launchpad is a very large project and even seasoned developers get lost in the undergrowth from time to time. Thankfully, there’s a team of committed people who are able to wade in with machetes and rescue them. I’m going to stop this analogy now, since it’s starting to wither.

What to do once you’re written code

Once you’ve finished hacking on your branch, you need to get it reviewed. Launchpad has a feature that makes this really, really simple, called Merge Proposals. Here’s how it works.

First, commit your changes to your branch (you should have been doing this all along anyway, but just in case…) and push them to Launchpad:

$ bzr ci -m "Here are some changes that I made earlier, with a useful commit message."
$ bzr push
Using saved push location: lp:~yourname/launchpad/my-branch-for-bug-12345
Using default stacking branch /+branch-id/24637 at chroot-83246544:///~yourname/launchpad/
Created new stacked branch referring to /+branch-id/24637.

You can now view the branch on Launchpad by using the bzr lp-open command:

$ bzr lp-open
Opening https://code.launchpad.net/~yourname/launchpad/my-branch-for-bug-12345 in web browser

The page that will open in your browser contains a summary of the branch you’ve pushed, and will look something like this:

You can link it to the bug you’re fixing by clicking “Link a bug report”. If you’ve named your branch something like “foo-bug-12345”, Launchpad will guess that you want to link it to bug 12345 in order to save you some time.

From the branch summary page, you need to create a merge proposal. To do this, click “Propose for merging.” You’ll be presented with this page:

 

 

On this page, you’re going to explain what you’ve changed and why. There’s a template for what we refer to as the merge proposal cover letter on the Launchpad dev wiki.

Things you absolutely must include in your cover letter:

  • A summary of the problem.
  • A summary of your proposed solution.
  • Details of your solution’s implementation.
  • Instructions on how to test your solution and how to QA it.
Not all of the other items in the template will apply to your branch. If there’s any confusion, just ask for clarification in #launchpad-dev.
Once you’ve entered all your branch’s details in the “Description of change” field, click the “Propose merge”  button to create the merge proposal. Once you’ve done that, hop over to #launchpad-dev on Freenode and talk to the On-call reviewer (listed in the channel topic), who will review your branch for you and, once it’s ready, land it on the Launchpad mainline. If there’s no on-call reviewer listed you can find out who should be available for that day by taking a look at the reviewer schedule. If all else fails, a general call for a reviewer should net you a willing Launchpad developer, though you’ll have to wait for them to have time in their day to take a look at your branch.

Launchpad Clinic – UDS 

At UDS-Q we’re going to run two day with the help of Graham Binns who will be there to help with hands on set up and walk people through their bugs they would like to work on  and figure out where to start.  If you’re interested in taking part in these sessions, please add your name and the bug(s) you are interested in so we can review them ahead of time, there are many to chose from that are tagged with trivial if you want to start there.

We will have a EC2 instance set up of Launchpad to maxamise the time available to work on these areas.