Colin Watson is not a high-profile Debian figure, you rarely see him on mailing lists but he cares a lot about Debian and you will see him on Debconf videos sharing many thoughtful comments. I have the pleasure to work with him on dpkg as he maintains the package in Ubuntu, but he does a lot of more interesting things. I also took the opportunity to ask some Ubuntu specific questions since he’s worked for Canonical since the start. Read on.

My questions are in bold, the rest is by Colin.

Who are you?

Hi. I’m 32 years old, grew up in Belfast in Northern Ireland, but have been living in Cambridge, England, since I was 18. I’m married with a stepson and a daughter.

I became interested in Debian due to the critical mass of Debian work happening in Cambridge at the time (and perhaps more immediately because my roommate was running Debian: “hey, what’s that?”), started doing random bits of development in 2000, and joined as a developer in 2001 (a really exciting time, with lots of new people joining who became integral parts of the project). I’d only really been intending to do QA work and various bits of packaging around the edges, and maybe some work on the BTS, but then Fabrizio Polacco died and I took over man-db from him, and it sort of snowballed from there.

I graduated from university shortly before becoming a Debian developer. I worked for a web server company (Zeus), then a hardware cryptography company (nCipher), before moving to work for Canonical in 2004, since when I’ve been working full-time on Ubuntu. By this point, I suspect that going back to work in an office every day would be pretty tough.

What’s your biggest achievement within Debian or Ubuntu?

One thing I should say: I rarely start projects. Firstly I don’t think I’m very good at it, and secondly I much prefer coming on to an existing project and worrying away at all the broken bits, often after other people have got bored and wandered off to the next new and shiny thing. That’s probably why I ended up in the GNU/Linux distribution world in the first place, rather than doing lots of upstream development from the start – I like being able to polish things into a finished product that we can give to end users.

So, I’ve had my fingers in a lot of pies over the years, doing ongoing maintenance and fixing lots of bugs. I think the single project I’m most proud of would have to be my work on the Debian installer. I joined that team in early 2004 (a few months before Canonical started up) partly because I was a release assistant at the time and it was an obvious hot-spot, and partly because I thought it’d be a good idea to make sure it worked well on the shiny new G4 PowerBook I’d just treated myself to. I ended up as one of the powerpc d-i port maintainers for a while (no longer, as that machine is dead), but I’ve done a lot of core work as well: much of the work to put progress bars in front of absolutely everything that used to have piles of text output, rescue mode, the current kernel selection framework, a good deal of udev support, several significant debconf extensions, lots of os-prober work, and I think I can claim to be one of the few people who understands the partitioner almost top to bottom.

d-i is the very first thing many of our users see, and has a huge range of uses, from simple desktop installs to massive corporate deployments; it’s unspeakably important that it works well, and it’s a testament to its design that it’s been able to trundle along without actually very much serious refactoring for the best part of five years now.

I have a soft spot for man-db too. It was my first major project in Debian, starting out from an embarrassingly broken state, and is now nice and stable to the point where I recently had time to spawn a useful generic library out of it (libpipeline).

What are your plans for Debian Wheezy?

d-i has a lot of code to deal with disks and partitions. Of course a lot of it is in the partitioner, and for that we use libparted so we don’t have to worry very much about the minutiae of device naming. But there are several other cases where we do need to care about naming, mainly before the partitioner when detecting disks, and after the partitioner when installing the boot loader. Back in etch, we introduced ‘list-devices’, which abstracted away the disk naming assumptions involved in hardware detection. In wheezy, I would like to take all the messy, duplicated, and error-prone code that handles disk naming in the boot loader installers, and design a simple interface to cover all of them. This has only got more important following the addition of the kFreeBSD and Hurd d-i ports in squeeze, but it bites us every time we notice that, say, CCISS arrays aren’t handled consistently, and it’s a pain to test all that duplicated code.

I’d also like to spread the use of libpipeline through C programs in the archive, which I think has potential to eliminate a class of security vulnerabilities in a much simpler way than was previously available.

If you could spend all your time on Debian, what would you work on?

I would love to systematically reduce the need for the current mass of boot loaders. There’s a significant cost to having so much variation across architectures here: it’s work that needs to be done in N different places, the wildly differing configuration means that d-i has to have huge piles of code to manage them all differently, and there are a bunch of strange arbitrary limitations on what you can do.

The reason I’m working on GRUB 2 is that, in my view, it’s the project with the best chance of centralising all this duplicated work into a single place, and making it easier to bring up new hardware in future (in a way that doesn’t compromise software freedom, as many proprietary boot loaders of the kind often found on phones do). Of course, with flexibility tends to come complexity, and some people have a natural objection to that and prefer something simpler. The things I don’t quite have time to do here are to figure out a coherent way to address the specific over-complexity problems people have with the configuration framework while still keeping the flexibility we need, and to do enough QA and porting work to be able to roll out GRUB 2 at installation time to all the Debian architectures it theoretically supports.

What’s the biggest problem of Debian?

Backbiting, and too much playing the man rather than the ball. With one or two honourable exceptions, I’ve largely stopped reading most Debian mailing lists since it just never seems a productive way to spend time compared to writing code and fixing bugs; and yet I’m conscious that they’re one of the primary means of communication for the project and I’m derelict in not taking part in them.

I do find it a bit frustrating that people are seen primarily in terms of their affiliations. I suppose it’s natural for people to see me as an “Ubuntu guy”, but I don’t really see myself that way: I’ve been working on Debian for nearly twice as long as I’ve been working on Ubuntu, and, while I care a great deal about both projects, I’ve put far more of my own personal time into Debian and I try to make sure that a decent number of the things I’m involved with there aren’t to do with work. Work/life separation is a good thing, not that I’m very good at it. Generally speaking, when I’m working on Debian, I’m doing so as a Debian developer, because I want Debian to be better. When that’s not the case, if it matters, I try to indicate it explicitly.

You’re working for Canonical since Ubuntu’s inception. If you were Mark Shuttleworth, is there something that you would have done differently?

We had many good intentions when we founded Ubuntu. We also had a huge amount of work to deliver, to the point where it wasn’t at all clear whether it would be possible (the warty release was named based on the expectations of it, after all, and came out much more usable than we’d dared to hope). In hindsight, it might have helped to be quieter about our good intentions, so that we could exceed expectations rather than in some cases failing to meet them. That might have set a very different tone early on.

(Personally, I’m happy I’m not Mark. The decisions in my office are much easier to take.)

It seems to me that the community part of Ubuntu is much more eager to cooperate with Debian than the corporate part. It’s probably just that more and more Canonical employees are not former Debian contributors. Do you also have this feeling? Are there processes in place to ensure everybody at Canonical is trying to do the right thing towards Debian cooperation?

Just to be clear, I’m wearing my own hat here—which, ironically, is a fedora—rather than a company hat.

It makes sense for Canonical to be taking on more non-Debian folks; after all, we can’t simply hire from the Debian community forever, and a variety of backgrounds is healthy. As you say, it may well be natural that Ubuntu developers who don’t work for Canonical are more likely to have a Debianish background, as it tends to take something significant to get people to switch to a very different family of GNU/Linux distributions, and changing jobs is one of the most obvious of those things.

Certainly, there was a definite sense among the early developers that we were all part of the Debian family and cared about the success of Debian as well. As Ubuntu has developed its own identity, people involved in it now tend to care primarily about the success of Ubuntu. At the same time, pragmatically, it’s still true that getting code changes into Debian is one of the most economical ways to land them; changes made in Debian or upstream land once and tend to stay in place, while changes made only in Ubuntu incur an ongoing merge overhead, which is not at all trivial.

In many ways it’s human nature to try to fulfil your immediate goals in the most direct way possible. If your goal is to deliver changes to Ubuntu users, then it’s natural to concentrate on that rather than looking at the bigger picture (which takes experience). Debian developers often fail to send changes upstream for much the same reason, although there’s more variation there because they’re normally working on Debian of their own volition and thus tend to have wider goals; the economics are more or less parallel though.

Thus, I think the best way to improve things is to make it the path of least resistance for Ubuntu developers to send changes to Debian. We’re already seeing how this works with the Ubuntu MOTU group; if you send a patch for review, or work on merging a package from Debian, very often the response includes “have you sent these changes to Debian?”. We’re working on both streamlining our code review through a regular patch pilot programme and requiring more code review for changes in general, so I think this will be a good opportunity to ask more people to work with Debian when they propose changes to Ubuntu.

For myself, this may be obvious, but I notice that I’m much better at getting changes into Debian when I already have commit access to the Debian package in question. All the work on improving collaborative maintenance in Debian can only help, for Ubuntu as well as for everyone else. It doesn’t make so much difference for large changes that require extensive discussion, but there are lots of small changes too.

Canonical is upstream of many software projects (unity, indicators infrastructure, etc.). Why aren’t those software immediately packaged in Debian? Do you think we can get this to change?

I’m not sure what the right approach is here, particularly as I haven’t been involved with much of that on the Ubuntu side. I suspect it would be helpful to look at this in a similar way to Ubuntu changes in general. It’s understandable that those developers have getting changes into Ubuntu as their first goal. And yet, having code in Debian offers a wider, and often technically adept, audience, and most developers like having their code reach a wider audience even if it’s not their first priority, particularly if that audience is likely to be able to help with finding problems and fixing bugs. It should be seen as something beneficial to both distributions.

The hardest problems will be with things that aren’t merely optional add-ons (which should generally be fairly non-controversial in Debian, given the breadth of the archive in general – the existence of things like bzr and germinate as Debian packages was never a hard question), but which require changes in established packages. For example, gnome-power-manager in Ubuntu is built with application indicator support, and that’s an important part of having a good indicator-based panel: a lot of the point of indicators is consistency. Since I do very little desktop work myself, I don’t know exactly what would be involved in making it possible to choose this system based on a Debian desktop, but I think it’s probably a bit more complicated than just making sure all the new packages exist in Debian too. Obviously you have to start somewhere.

Is there someone in Debian that you admire for his contributions?

Christian Perrier is absolutely tireless and has done superb things for the state of translations in Debian. And Russ Allbery, even aside from his fine ongoing work on policy, Lintian, and Kerberos, is a constant voice of sanity and calmness.

Release management is incredibly hard work, as I know from my own experience, and anyone who can sustain involvement in it for a long period is somebody pretty special. Steve Langasek and I got involved at about the same time but he outlasted me by quite a few years. He deserves some kind of medal for everything he’s done there.

Thank you to Colin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.