People behind Debian: Peter Palfrader, Debian System Administrator

You might not know who Peter is because he’s not very visible on Debian mailing lists. He’s very active however and in particular on IRC. He was an admin of the OFTC IRC network at the time Debian switched from Freenode to OFTC. Nowadays he’s a member of the Debian System Administration team who runs all the servers.

If you went to a Debconf you probably met him since he’s always looking for new signatures of his GPG key. He owns the best connected key in the PGP web of trust. He also wrote caff a popular GPG key signing tool.

Raphael: Who are you?

Peter: I’m Peter Palfrader, also known as weasel. I’m in my early 30s, born and raised in Innsbruck, Austria and am now living and working in Salzburg, Austria. In my copious free time, other than help running Debian’s servers I also help maintaining the Tor project‘s infrastructure.

Away from the computer I enjoy reading fiction (mostly English language Science Fiction and Fantasy), playing board games and going to the movies. Weather permitting, I also occasionally do some cycling.

Raphael: How did you start contributing to Debian?

Peter: I installed my first Debian the week slink came out. That was Debian 2.1 for the youngsters, in early 1999. The one thing I immediately liked about slink was that Debian’s pppd supported RAS authentication which my university’s dial-up system required. No way I’d go back to SuSE 5.3 when I had working Internet with my Debian box. :)

During that year I started getting involved in the German language Debian channel on IRCnet which got me in contact with some DDs. Christian Kurz (<shorty>) was working on Debian QA at the time and he asked my help in writing a couple of scripts. Some of that work, debcheck, still produces parts of the qa.d.o website, tho the relevance of that nowadays is probably negligible.

While trying to learn more Perl earlier, I had written a program to produce syntax highlighted HTML for code snippets in various languages. I didn’t really know what I was doing but it kinda worked, and probably still does since I still get mail from users every now and then. I figured that it would be really nice if people could just get my software together with Debian. According to code2html‘s Debian changelog the initial release of the package was done on a weekday at 2:30 in the morning early in 2000, and if my memory serves me correctly, shorty uploaded it shortly afterwards.

I started packaging a couple of other piece of software and in the same year I sent my mail to the debian account managers to register my intent to become a DD. No new developers where being accepted at that time since the DAMs wanted to overhaul the entire process so I wasn’t surprised to not get any immediate reply. Of course what the silence also meant was that the mail had been lost, but I only learned of that later when I took all my courage to ask DAM about the status of application a couple months later. Once that was sorted out I was assigned an AM, did the usual dance, and got my account late in November 2000.

Raphael: Four years ago, the Debian System Administration team was a real bottleneck for the project and personal conflicts made it almost impossible to find solutions. You were eager to help and at some point you got dropped as a new member in that team. Can you share your story and how you managed the transition in the difficult climate at that time?

Peter: Ah, that was quite the surprise for an awful lot of people, me included.

Branden Robinson, who was our DPL for the 2005-2006 term, tried to get some new blood added to DSA who were at the time quite divided. He briefly talked to me on IRC some time in summer 2005, telling me I had come “recommended for a role on the sysadmin team”. In the course of these 15 minutes he outlined some of the issues he thought a new member of DSA would face and asked me if I thought I could help. My reply was cautiously positive, saying that I didn’t want to step on anybody’s toes but maybe I could be of some assistance.

And that was the first and last of it, until some fine November day two years later I got an email from Phil Hands saying “I’ve just added you to the “adm” group, and added you to the debian-admin@d.o alias.” and “welcome on board“. *blink* What!?

My teammates at the time were James Troup (elmo), Phil Hands (fil), Martin ‘Joey’ Schulze and Ryan Murray (neuro).

The old team, while apparently not on good terms with one another, was however still around to do heavy lifting when required. I still remember when on my first or second day on the team two disks failed in the raid5 of aka ries. Neuro did the reinstall once new disks had arrived at Brown University. I’m sure I’d have been way out of my league had this job fallen to me.

Fortunately my teammates were all willing and able to help me find whatever pieces of information existed that might help me learn how does its stuff. Unfortunately a lot of it only existed in various heads, or when lucky, in one of the huge mbox archives of the debian-admin alias or list. Anyway, soon I was able to get my hands dirty with upgrading from sarge to etch, which had been released about half a year earlier.

Raphael: I know the DSA team has accomplished a lot over the last few years. Can you share some interesting figures?

Peter: Indeed we have accomplished a lot. In my opinion the most important of these accomplishment is that we’re actually once again a team nowadays. A team where people talk to one another and where nobody should be a SPoF.

Since this year’s debconf we are six people in the admin team: Tollef Fog Heen (Mithrandir) and Faidon Liambotis (paravoid) joined the existing members: Luca Filipozzi, Stephen Gran, Martin Zobel-Helas, and myself. Growing a core team, especially one where membership comes with uid0 on all machines, is not easy and that’s why I’m very glad we managed to actually do this step.

I also think the infrastructure and our workflows have matured well over the last four years.

We now have essential monitoring as a matter of course: Nagios not only checks whether all daemons that should be running are in fact running, but it also monitors hardware health of disks, fans, etc. where possible. We are alerted of outstanding security updates that need to be installed and of changes made to our systems that weren’t then explicitly acked by one of us.

We have set up a centralized configuration system, puppet, for some of our configuration that is the same, or at least similar, on all our machines.

Most, if not all, pieces of software, scripts and helpers that we use on infrastructure is in publicly accessible git repositories.

We have good communication with other teams in Debian that need our support, like the ftp folks or the buildd people.

As for figures, I don’t think there’s anything spectacular. As of the time of our BoF at this year’s DebConf, we take care of approximately 135 systems, about 100 of them being real iron, the other virtual machines (KVM). They are hosted at over 30 different locations, tho we are trying to cut down on that number, but that’s a long and difficult process.

We don’t really collect a lot of other figures like web hits on or downloads from the ftp archive. The web team might do the former and the latter is pretty much impossible due to the distributed nature of our mirrors, as you well know.

Raphael: The DSA team has a policy of eating its own dog food, i.e. you’re trying to rely only on what’s available in Debian. How does that work out and what are the remaining gaps?

Peter: Mostly Debian, the OS, just meets our needs. Sure, the update frequency is a bit high, we probably wouldn’t mind a longer release cycle. But on the other hand most software is recent enough. And when it’s not, that’s easy to fix with backports. If they aren’t on already, we’ll just put them there (or ask somebody else to prepare a backport for us) and so everybody else benefits from that work too.

Some things we need just don’t, and probably won’t, exist in Debian. These are mainly proprietary hardware health checks like HP’s tools for their servers, or various vendors’ programs to query their raid controller. HP actually makes packages for their stuff which is very nice, but other things we just put into /usr/local, or if we really need it on a number of machines, package ourselves.

The push to cripple our installers and kernels by removing firmware was quite annoying, since it made installing from the official media next to impossible in some cases. Support for working around these limitations has improved with squeeze so that’s probably ok now.

One of the other problems is that especially on embedded platforms most of the buildd work happens on some variation of development boards, usually due to increased memory and hard disk requirements than the intended market audience. This often implies that the kernel shipped with Debian won’t be usable on our own machines. This makes keeping up with security and other kernel fixes way more error prone and time intensive. We keep annoying the right people in Debian to add kernel flavors that actually boot on our machines, and things are getting better, so maybe in the future this will no longer be a problem.

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

Peter: One of the things that I think is a bit annoying for admins that maintain machines all over the globe is mirror selection. I shouldn’t have to care where my packages come from, apt-get should just fetch them from a mirror, any mirror, that is close by, fast and recent. I don’t need to know which one it was.

We have deployed geodns for a while ago, and it seems to work quite well for the coarse granularity we desired for that setup, but geodns is an ugly hack (I think it is a layer violation), it might not scale to hundreds or thousands of mirrors, and it doesn’t play well with DNSSEC.

What I’d really like to see is Debian support apt’s mirror method that — I think (and I apologize if I’m wronging somebody) — Michael Vogt implemented recently. The basic idea is that you simply add deb mirror:// or something like that to your sources.list, and apt goes and asks that server for a list of mirrors it should use right now.

The client code exists, but I don’t know how well tested it is. What is missing is the server part. One that gives clients a mirror, or list of mirrors, that are close to them, current, and carry their architecture.

It’s probably not a huge amount of work, but at the same time it’s also not entirely trivial. If I had more time on my hands this is something that I’d try to do. Hopefully somebody will pick it up.

Raphael: What motivates you to continue to contribute year after year?

Peter: It’s fun, mostly. Sure, there are things that need to be done regularly that are boring or become so after a while, but as a sysadmin you tend to do things once or twice and then seek to automate it.

DSA’s users, i.e. DDs, constantly want to play with new services or approaches to make Debian better and often they need our support or help in their endeavors. So that’s a constant flow of interesting challenges.

Another reason is that Debian is simply where some of my friends are. Working on Debian with them is interacting with friends.

I not only use Debian at I use it at work, I use it on my own machines, on the servers of the Tor project. When I was with OFTC Debian is what we put on our machines. Being a part of Debian is one way to ensure what Debian releases is actually usable to me, professionally and with other projects.

Raphael: Is there someone in Debian that you admire for their contributions?

Peter: That’s a hard one. There are certainly people who I respect greatly for their technical or other contributions to Debian, but I don’t want to single anybody out in particular. I think we all, everyone who ever contributed to Debian with code, support or a bug report, can be very proud of what we are producing — one of the best operating systems out there.

Thank you to Peter 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, Twitter and Facebook.

People behind Debian: Margarita Manterola, Debian Women member

Photograph taken by Julia Palandri

When I think about Margarita, I always remember her as a friendly and welcoming person. Like most of the Debian Women members by the way. But she likes to spread some love and organized a Debian Appreciation Day for example.

I think I met her in real life for the first time at Debconf 6 in Oaxtepec (Mexico). She deeply cares about Debian in general. She has proven it multiple times with her DPL candidacy and by giving talks like Making Debian rule again.

One last thing, Debconf11 is just over and you will see that Debconf4 has had a big influence on Marga. My advice is simple: next time there’s a Debconf on your continent, make sure to take a few days off and come to meet us! It really gives another picture of the Debian community. Now let’s proceed with the interview.

Raphael: Who are you?

Margarita: I’m Margarita Manterola, a Software Developer from Argentina. I work developing software in Python in a Debian-friendly company during the day, and teach programming at a local university during the evenings.

I’m married to Maximiliano Curia who is also a Debian Developer, most of our Free Software work has been done together.

I only maintain a handful of packages in Debian, I’m more interested in fixing bugs than in packaging new software.

I’ve also been a part of the organizing team of many of the previous Debian Conferences. One of the biggest commitments and the biggest success of my participation in Debian was being part of the organizing team of DebConf8, in Argentina.

Raphael: How did you start contributing to Debian?

Margarita: I started using Debian around 2000. Soon after we had learned the grips of general GNU/Linux usage, Maxy and I started giving an introductory course at our local university, and became quite involved with the local LUG.

At some point in 2002/2003 I became a “Debian Bug Reporter”: most of my friends would report bugs to me, and I would then write them in the proper form to the BTS. I would also be very attentive about reporting any bugs that I might encounter myself trying to create good bug reports.

The turning point in my participation in Debian was DebConf4 in Porto Alegre, Brazil. Being so close to Argentina meant that we felt specially invited to be there, and Maxy and I decided to go to DebConf for our honeymoon. We didn’t really know much about DebConf dynamics, but we were really eager to learn more about Debian and become more involved.

What happened was that meeting with DDs from all over the world transformed our lives, we became part of the “Debian family” and wanted to be more and more involved. Soon after that we both started maintaining packages and not long after that, applied to become Developers.

The Debian Women project also meant a lot to me. I felt encouraged all along the way, encouraged to learn, to ask questions and to lose the fear of making mistakes.

I became a Debian Developer on November 2005. Since then, Debian has always been one of the most important things I do in my life.

Raphael There was a Debian Women BoF during debconf. What are the plans for Debian Women in the upcoming months?

Margarita: I was not there in person, but thanks to the awesome work of the video team, and of Christian Perrier’s typing efforts when something failed, I was able to experience much of what was discussed. :)

One of the many points that came up during the BOF is that many people “Want to help” but don’t know where to start or how to go about it. It’s a challenge for the Debian Women project to find a way to allow these people to become involved in Debian through “Mini projects” or something like that.

Another of the subjects that was brought up was the Debian Women mentoring project, which has been going on for quite a while now, but lacks enough publicity. So, we need to reach more people about it, and maybe also improve it with some templates, similar to the New Maintainer templates, so that mentees that don’t know where to start have some sort of general path to follow.

Raphael: You created very useful diagrams documenting how package maintainer scripts are invoked by dpkg. How did you do it and was that a useful experience?

Margarita: I did those diagrams to be able to answer one of the questions in the NM templates, regarding the order of the maintainer script execution.

Answering the question in text was basically copying and pasting the part of the Debian Policy that explained it, which wasn’t really too clear for me, so I decided to go and make a diagram of it, so that I could really understand it.

I did it by the best of all debugging techniques: adding prints to each of the maintainer scripts, and testing them in all the different orders that I could think of.

It was a useful experience at the time, because I learned a lot of how maintainers scripts work. I didn’t expect the diagrams to become so famous, though, I only did them to answer one NM question, that I assumed most other people had already answered before :)

Raphael: You participated in a DPL election. This is a big commitment to make. What were your motivations?

Margarita: As I said, I was part of the organizing team of DebConf8, in Argentina. Which was quite a success, a lot of people enjoyed it and praised the good work that had been done by the local team.

During said DebConf8, I had a dream (it was almost a nightmare, actually): I woke up and just like that, I was the DPL. I spoke to some people about this dream and to my complete surprise many said that I should actually do it.

After giving that possibility a year and a half of thoughts, during the 2010 campaign I was talked into participating myself as a candidate, and it was a very interesting experience. However, I’m very glad that Zack got elected and not me, I think he makes a much better DPL that I would have made.

Raphael: What’s the biggest problem of Debian?

Margarita: I think the main problem that we have is our communication, both inside the project and outside the project. Most of us are very technical people, our skills lay in the technical part of Debian (preparing packages, fixing bugs, writing software, administering systems) not in the social part. And thus, we lack a general empathy that is quite needed when interacting with people from all over the world.

Raphael: Do you have wishes for Debian Wheezy?

Margarita: Not particularly. I do want it to be a great release with good quality, stable software. I would also like to keep making Debian more and more “universal” with each release, making it more user friendly, more accessible, and more robust than any other previous release.

Raphael: Is there someone in Debian that you admire for their contributions?

Margarita: I admire a lot of people in Debian. There’s a lot of people that contribute a lot of time to Debian, amounts of time that I can’t begin to understand how they can afford.

I admire Stefano Zacchiroli, our current project leader. And Steve McIntyre, the project leader before him. Also Bdale Garbee, who’s also been a DPL in the past. Making this list I realize that Debian has been blessed by quite a number of great leaders in the past.

I admire Holger Levsen, for his contributions to the DebConf video team, that have made it possible year after year for the whole project to participate in DebConf remotely.

I admire Steve Langasek and Andreas Barth (etch is still my favourite release). I admire Christian Perrier for his work on internationalization. I admire Joerg Jaspert for the incredible amounts of time that he puts into Debian.

And actually, I could go on admiring people all night long. I admire so many people that this interview could become a very boring list of names. I guess it’s better to leave it at saying that Debian is lucky to have quite a lot of excellent hackers around.

Thank you to Marga for the time spent answering my questions. I hope you enjoyed reading her 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, Twitter and Facebook.

People behind Debian: Martin Michlmayr, former Debian Project Leader

Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in 2003 and 2004.

He’s no longer as active as he used to be but his input is always very valuable and he continues to do very interesting things in particular concerning the support of NAS devices. Read on for the details.

Raphael: Who are you?

Martin: I’m Martin Michlmayr. I’m 32, originally from Austria, and currently living in the UK.

I’ve contributed to various free software projects over the years but Debian is without doubt the one I’m most passionate about. I joined Debian in 2000 when I was a student. I worked on Debian more or less full time for a few years while I was pretending to study. Later I started a PhD to do research about quality and management aspects of volunteer free software projects. I investigated the release process in several free software projects, in particular looking at time-based releases. After finishing my PhD in 2007, I joined Hewlett-Packard. I’m part of HP’s Open Source Program Office and work on various free software and open source activities, both internally and within the community.

Raphael: How did you start contributing to Debian?

Martin: I first used Debian in the days of 0.93R6, some time around the end of 1995. The 0.93R6 release was still based on a.out but I needed an ELF-based system for some application, so I moved to Slackware. I then quickly moved to Red Hat Linux where I stayed for several years. I rediscovered Debian in 2000 and quickly decided to join the project. I cannot recall how I rediscovered Debian but when I did, it was clear to me that Debian was the ideal project for me: I could identify with its philosophy, I liked the volunteer nature of the project, and I found the size and diversity of Debian interesting since a large project offers a lot of different challenges and opportunities.

I remember how many new things there were to learn and back then the documentation and other resources for new contributors were nowhere as good as they are today. My application manager, Julian Gilbey, was a great help… he was incredibly friendly and passionate about Debian. I also remember meeting up with Peter Palfrader (weasel) for key signing when we were both in the New Maintainer queue. I was incredibly lucky with my New Maintainer process and soon became an official Debian Developer. Because there was a shortage of application managers, my first major contribution in Debian was to become an application manager myself and help other people join the project.

Debian is a large project with a long history and a rich culture, so new contributors should expect that it will take some time to become familiar with everything. Fortunately, there are many resources, such as documentation and the debian-mentors list, for new contributors. Another great way to become familiar with the way things are done in Debian is to subscribe to various Debian mailing lists and ideally to read some mailing list archives. It’s also a great idea to attend the Debian Conference or other conferences since meeting people in real life is a great way to integrate. I remember attending Debian Conference 1 in Bordeaux where I gave my first public talk.

Finally, new contributors should find an area where they can make a unique contribution. Most people in Debian maintain packages but there are so many other ways to contribute. For example, most of my contributions were not technical but were about coordination and other organizational activities.

Raphael: What’s your biggest achievement within Debian?

Martin: I’m particularly proud of a number of achievements:

  • New Maintainer: I helped a lot of people join Debian. It’s great to help someone join the project and then see how they contribute. Of course, some people join Debian and then quickly become inactive or retire… you never know in advance how it will work out. But I had the pleasure to help some truly outstanding contributors to join Debian.
  • Quality Assurance: I helped improve QA processes within Debian. In particular, I realized a few years ago that a lot of packages had maintainers who were inactive and that nobody did anything about it. I started to write to those maintainers to see what could be done. It’s hard because you don’t know the circumstance of someone… they may be inactive because of an illness or for other good reasons… so you have to be friendly, but yet persistent. Fortunately, most maintainers I contacted were truly inactive and so they couldn’t complain when I took their packages away.
  • DPL: I acted as the Debian Project Leader for two years. I’m particularly proud of this because Debian is a great project and it was an honour to represent it. I performed important organizational and coordination tasks. I also traveled to a lot of conferences and had the pleasure to meet many Debian Developers as well as users of Debian. It’s very motivating to meet users and to hear how they use Debian and how we can further improve it.
  • Debian on NAS: Debian is without the doubt the Linux distro with the best support for NAS (Network Attached Storage) devices. I was always impressed by what the OpenWRT folks have done to support wireless routers and wanted to do something similar for Debian. Unfortunately, wireless routers just don’t have enough storage for a full distro. But then NAS devices came along and they obviously have enough space since they are meant for storage.

Raphael: Speaking about NAS devices: what exactly are you doing on this topic and how can people help?

Martin: There are plenty of instructions on the Internet to install Linux distributions on NAS or various embedded devices by connecting a serial console and then typing in hundreds of commands. What I found is that such instructions significantly limit the user base because they are way too complicated for most users. There are just too many steps that can go wrong.

So instead, in Debian, we provide a solution that just works: usually, you download a firmware image for your NAS device from Debian and when you upgrade you get the Debian installer. You connect to the installer via SSH and perform a normal installation. The installer knows about the device and will prepare everything for you automatically… for example, it knows if the device has requirements for the partition layout and it will install the kernel where the device expects to find it; unfortunately, NAS devices are not like PCs, so the requirements are different for almost every device and therefore you need special code to support a new device. Finally, there are detailed installation guides and we provide help on our mailing lists.

There are a number of technical areas for improvement. The installation could be made even easier, and it would be nice to support new platforms and devices.

A bigger problem is that while we’ve implemented a great solution for NAS devices, we haven’t really extended this work to support other classes of devices. For example, tablets and mobile phones are getting incredibly popular and we don’t have a compelling solution for such devices, mostly because of the lack of an appropriate GUI.

Raphael: What are your plans for Debian Wheezy?

Martin: I’ve recently been asked by Stefano Zacchiroli, our current Debian Project Leader, to coordinate the care-taking of Debian finances. Debian, as a volunteer project, relies on donations and in-kind gifts (e.g. hardware) to maintain its infrastructure and to support various development efforts, such as funding sprints and other developer gatherings. Debian’s money and other assets are held by affiliate organizations around the world.

My responsibility will be to keep track of money and other assets (e.g. hardware and trademarks), work with the DPL to establish procedures related to the use of Debian’s assets, and make sure that the procedures are followed. Finally, we want to publish public statements so our donors know how we use their donations to further improve Debian. I just started working on this and this will be my main activity in Debian in the coming months.

Raphael: Speaking of money, I plan to run a fundraising to get the Debian book I wrote with Roland Mas translated (cf. Is this something Debian should support?

Martin: First of all, I should make it clear that I don’t decide how Debian spends its money. This is up to the DPL to decide together with the project at a whole. I’ll just make sure that procedures are followed and expenses tracked and reported properly.

Having said that, in my opinion, it’s unlikely that Debian as a project will fund this effort. It would be inconsistent with the position of the project not to fund work directly (only some related expenses, such as travel costs to allow Debian teams to organize face-to-face meetings). Whether Debian should support the fundraising effort by helping to promote it is another question and that’s probably not as clear cut. It looks like a worthwhile effort, but on the other hand it would be unfair for authors of other Debian books for Debian to put its weight behind one… and there are many other efforts that are worth promoting… if you promote one, where do you stop? So while it sounds worthwhile, it’s probably better for Debian to stay out of it.

But somehow related to this, I sometimes worry about the fact that there are so few paid opportunities around Debian. If you contribute to the Linux kernel for a while, you have an excellent chance to get hired by someone and to work on the kernel full time. The kernel may be an extreme example but there are a lot of projects that have more paid opportunities than Debian, e.g. Mono, GNOME, OpenOffice/LibreOffice and KDE.

Obviously, there are some Debian Developers who can spend some time on Debian as part of their job. I know that some Canonical employees contribute to Debian, that support companies like credativ improve Debian as part of their work, and that system administrators fix bugs or package new software as they deploy Debian. But I think this is a minority of contributors and even they don’t work full time on Debian. Instead what I see is that a lot of people leave university, get a job and then no longer have time for Debian… or people start a family and no longer have time. I can take myself as an example since I don’t have nearly as much time as I did in the past when I was a student.

I guess there are different ways to deal with this problem… one would be to create more paid opportunities around Debian outside the project, another one might be to make it easier for new volunteers to join the project. I don’t have the answers to these questions… but it’s something I wonder about, and I also wonder whether pure volunteer projects can still keep up with projects with a lot of full time contributors.

Raphael: What motivates you to continue to contribute year after year?

Martin: Debian is a great project with a great mission, goals and people. I contribute to make Debian a better solution and to promote the free software philosophy. Finally, the community around Debian provides a lot of motivation. It’s amazing how much I’ve learned about other cultures because of my involvement in Debian and how many friends I’ve made over the years all around the world.

Raphael: Do you have wishes for Debian Wheezy?

Martin: Not really. I’m pretty happy with the way things are going at the moment. We have made a lot of organizational changes in the last few years from which the project has greatly benefited. I’m particularly pleased about the plans to adopt a time-based freeze.

Raphael: Is there someone in Debian that you admire for their contributions?

Martin: There are many people I admire greatly. I’d like to mention Joey Hess because he’s a great example to follow. He doesn’t get involved in politics, is easy to work with and does great technical work. In fact, he has made not one but several contributions that have completely changed Debian (debconf, debhelper, and debian-installer). Furthermore, Debian has a lot of contributors who have done great work over the years but who are not very vocal about it. People like Colin Watson or Peter Palfrader. Debian has many unique contributors and the list of people I admire is much longer than the few people I just mentioned.

Thank you to Martin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. He raised some interesting questions.

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, Twitter and Facebook.

People behind Debian: Sam Hartman, Kerberos package maintainer

Sam Hartman is a Debian developer since 2000. He has never taken any sort of official role within Debian (that is besides package maintainer), yet I know him for his very thoughtful contributions to discussions both on mailing lists and IRL during Debconf.

Until I met him at Debconf, I didn’t know that he was blind, and the first reaction was to be impressed because it must be some tremendous effort to read the volume of information that Debian generates on mailing lists. In truth he’s at ease with his computer much like I am although he uses it in a completely different way. Read on to learn more, my questions are in bold, the rest is by Sam.

Raphael: Who are you?

Sam: I’m Sam Hartman. I’m a 35-year-old software engineer. I am a principal consultant and co-owner of a small consulting company, called Painless Security. I started using Debian in the mid 1990’s around the time of the bo release. I ended up deciding to join the project as a developer in 2000.

Raphael: You’re blind and yet you’re using your computer as effectively as I am. Can you explain us how you setup your computer ?

Sam: I gave a talk at Debconf9 on how my computer is set up; you can watch the video for full details.

My main laptop runs Debian. I use the gnome-orca package as my primary screen reader. It speaks the Gnome desktop. It does a relatively good job of speaking Iceweasel/Firefox and Libreoffice.

While it does speak gnome-terminal, it’s not really good enough at speaking terminal programs that I am comfortable using it. So, I run Emacs with the Emacspeak package. Within that, I run the Emacs terminal emulator, and within that, I tend to run Screen. For added fun, I often run additional instances of Emacs within the inner screens.

Raphael: Are there important problems in Debian in terms of accessibility to blind people?

KDE documentation talks a lot about accessibility, but at least for blind users, the code completely fails to deliver. That means there are a lot of good packages a blind user cannot use.

The non-free Adobe Flash player has some accessibility, but it could be a lot better. The free alternatives have none.

The free PDF readers have basically no accessibility. You can use pdftotext, but you cannot actually read a PDF in a graphical application.

It’s way too easy for a misbehaving program to lock up the entire accessibility infrastructure. Gnash is a big culprit here: if my Iceweasel starts Gnash, there’s a good chance that either Iceweasel or the entire desktop will appear to hang from an accessibility standpoint. Other programs, including gksu tend to fail in this way.

Some of the more dynamic website features like pop up menus or selection lists are really difficult to find and click without causing them to disappear. This gets better and worse over time as the accessibility support in Iceweasel changes and as websites change.

Raphael: What’s your biggest achievement within Debian?

Sam: I decided to be a Debian developer because I thought that in 2000, Debian support for using enterprise security and infrastructure software was lacking. Back then, any software that included crypto functionality was segregated into a special non-us archive. Some of the software was missing; I started by packaging MIT Kerberos for Debian. Other software had security or enterprise features disabled in the packages. At the height of working on this, I was maintaining krb5, some SASL modules, PAM, some PAM modules,OpenAFS, a version of and Ssh with Kerberos support.

I was also involved in the effort to resolve the legal issues so that we could move security software into the main archive. I think this work has been a huge success. In fact, it’s been such a success that other people are now doing most of the work. I still maintain the krb5 package. When I started I felt like I was pushing against the flow trying to get people to add patches, sometimes even having to fork a package. However, now, I can maintain just one component and there are enough others who shared my original goal that the work continues.

These days, I’m working on something that’s an evolution of this enterprise security work. I’m packaging Project Moonshot for Debian and Ubuntu. Project Moonshot is a response to the wide variety of identity management systems such as OpenID, Oauth, SAML, and the like. Moonshot works to create an identity management approach that works well both for the web and for client-server and other applications.

The project is a lot of fun, but the role of Debian in the project is also interesting. One of the things we want to show with Moonshot is how our technology can be effective when it is integrated throughout a platform. To really show the potential it needs to work with as many applications in a given platform as possible.

The open and collaborative nature of the Debian community makes it possible to introduce a new technology and have that technology evaluated based on its merits. We don’t need huge business relationships or marketing deals to integrate our technology: we need some combination of doing the work ourselves and showing others the benefits of working with us. For someone trying to do innovative work, the Debian model is powerful.

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

Sam: I’d really love to work with the embedded Debian folks. The vision of a single source base that could be the stack from devices from small embedded devices all the way up to high-end servers is very appealing. Doing that with Debian involves a number of challenges. However with the right people working on meeting these challenges full-time, I think we could offer something promising. I’d also love to have the time to contribute to project infrastructure: working on the release team, helping ftpmaster, that sort of thing. However I don’t. I’m just happy that so much of my consulting practice involves working on open-source software.

Raphael: What’s the biggest problem of Debian?

Sam: There’s something really not right about how we transition libraries from unstable to testing. Every time I get involved in a library transition I’m shocked at how complicated it is and how disruptive it is both to testing and unstable. We need to look at technology and processes to break up the dependency snarles. For example we don’t have good archive tools for keeping old versions of libraries around to ease transitions.

If you haven’t thought about this issue you’ll probably say that I’m being overly picky and this can’t be the major problem for Debian. However, if you think about how much this impacts our ability to introduce things into unstable around the times of the freeze or about how much it slows the release process, you may begin to appreciate how big of an issue this is.

Raphael: Is there someone in Debian that you admire for their contributions?

Sam: There are a number of people who have been role models for me over the years. Anthony Towns really helped me understand a lot of what drives free-software projects and what needs to be true for positive motivation. Joey Hess showed us all that sometimes, social problems do have technical solutions. If the tools are so good that doing the right thing is far easier than any other course of action, quality improves.

Thank you to Sam 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, Twitter and Facebook.

People behind Debian: Philipp Kern, Stable Release Manager

Philipp is a Debian developer since 2005 and a member of the release team since 2008. Since he took the responsibility of Stable Release Manager, the process has evolved for the best. I asked him to explain how the release team decides what’s fit for stable or not.

His work on the buildd infrastructure is also admirable but I’ll let him describe that. My questions are in bold, the rest is by Philipp.

Who are you?

I’m a 24 year old Computer Science student, living in Karlsruhe, Germany. As a student assistant I’m currently in two jobs: one is taking care of getting our university IPv6 network in shape, or rather generally getting fringe technologies into the network. The second is taking care of a s390x machine in the basement which my faculty got sponsored recently. In my spare time I tend my Debian duties and I’m active in the student council (Fachschaft) as a sys-admin, software developer and until recently as treasurer.

I got accepted as a Debian Developer in 2005. I’m only really active since I was invited to join the Release Team in early 2008 after I contributed rewrites of some scripts that got lost in a disk crash of ftp-master. In late 2008 I also took on wanna-build/buildd duties.

What’s your notable achievement within Debian?

For one I worked on the deployment of a single buildd/sbuild combination over all of our buildds and I rebased it on the sbuild in the archive several times already. All buildds basically look the same on all architectures, with only few variations. The chroots are now also created in a mostly predictable manner.

Then we finally got build autosigning after years of constant poking. However the policy decision to allow it was made by the ftp-masters anyway, for which I’m grateful, as it eases the workload of the buildd maintainers, the Security Team and the Release Team quite a bit.

On the release side there’s the integration of volatile into the proper structures of Debian. But there I’m guilty for choosing the bad name squeeze-updates is, in comparision with security’s squeeze/updates. Let’s see if we can improve that for wheezy.

The policy for stable updates have changed over time. Can you summarize what kind of updates are allowed nowadays?

All the changes that were made to the policy were driven by the aim to keep stable (and to some lesser degree oldstable) usable throughout its lifetime.

I have to admit that we got slightly more liberal in what we accept since I took over. The previous stable update policy included the fixes of critical bugs that break the system in interesting ways and security fixes. We also opened up the possibility of including important fixes for annoying bugs on a case-by-case basis.

The whole “don’t update that much” part of the stable release management is rooted in “let’s don’t change the behaviour of a running system” and “let’s have as few regressions as possible”. We currently try to counter that with a review process that only allows self-contained fixes that were tested in unstable first, if applicable.

In the future I’d also like to have a feedback process that includes the users of the packages to report problems more early. In fact that’s also why we now send calls for testing to debian-stable-announce one week in advance (see this mail as an example).

So stable is updated through point releases that happen roughly every two months for stable and roughly every four for oldstable. They are accompanied by announcements and new CD/DVD sets.

To be able to push some updates with less delay to our users and to avoid that they have to pick them from proposed-updates, there is stable-updates. The current policy for this suite is available in this post on debian-devel-announce. It boils down to everything urgent like tzdata, regression fixes and volatile packages. We noticed that some packages in stable just weren’t useful anymore when they got updated through volatile. Hence those are folded into stable, too. We also relaxed the rules a bit so that leaf packages like clive, that rely on external websites not to change their URLs, can be updated too.

If somebody wonders what happened to the “and a half” releases… Those were intended to mark the inclusion of new hardware support (mostly by including a co-installable new kernel version). This kind of flag point release is thankfully no longer needed because our marvellous kernel team now backports certain hardware drivers to the kernel version in stable. They have some trouble soliciting test feedback for them, though. It would be cool if more people using stable could respond to their calls for testing.

What are your plans for Debian Wheezy?

Luckily the wanna-build/buildd side isn’t much dependent on release cycles. The stable release management also just takes care of what gets dumped on them by the testing RMs. 😉

The near-term goals are certainly:

  • getting d-i to use some development process in the archive that’s compatible with the normal flow of packages into testing and
  • hopefully getting wanna-build to use a sane SQL layout and hence better performance

Apart from that my work is mainly squashing the bugs on for the wanna-build part, so if you want something fixed, you need to report it, I’m afraid.

You have several roles within Debian, in particular stable release manager and member of the wanna-build team. Which role do you enjoy more and why?

So the regular duties of the SRM, apart from setting up policies, are reviewing requests for uploads to proposed-updates, accepting them, chasing builds and scheduling point releases. It’s mainly steady work. As for the Release Team it’s working in a fabulous team where everyone’s doing an awesome job.

For me the wanna-build role is holding the things together and fixing up stuff that breaks while the world continues to evolve. And occassionally taking a stab at the ftp-masters. So rather… different.

My heart is probably siding with the buildd side because it’s infrastructure but release work is fun, too.

What’s the biggest problem of Debian?

Mainly that we’re not quick in picking up new technologies and that we got slow on innovation. Distro-wide changes are usually a very big effort to coordinate and to finally complete. I guess people should be able to push fixes for release goals more eagerly into the archive.

Also it seems to me that many DDs are actually disengaging from the release process, especially during the freeze but also before, which makes me a bit sad. However I’m still not sure how we could counter that. As we’re all volunteers you can’t suddenly make others love the idea of releasing something together, I guess.

Do you have wishes for Debian Wheezy?

It’s getting old, but there’s certainly multiarch. Also a usable Python 3 is something I’d really appreciate.

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

Peter Palfrader did an awesome job of getting a nicely working team together for DSA and got many tasks as automated as they are now. It’s a pleasure to work with them and setting up a new buildd is, for example, a real breeze. He also developed a sane archive snapshot service, kudos for that.

Thank you to Philipp 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, Twitter and Facebook.

People behind Debian: Steve Langasek, release wizard

Steve Langasek has been contributing to Debian for more than a decade. He was a release manager for sarge and etch, and like many former release managers, he’s still involved in the Debian release team although as a release wizard (i.e. more of an advisory role than a day-to-day contributor). Oh, and he did the same with Ubuntu: on the picture on the left, he just announced the release of Ubuntu 10.04 from his Debian-branded laptop. 😉

He has also been maintaining PAM in Debian for as long as can I remember and does a great job at that. He’s very knowledgeable and fully deserves his place within the Debian Technical Committee. I’m glad he still has the time to participate on several important Debian mailing lists because his contributions are always very useful.

I’m sure you’ll notice this just by reading his answers below. My questions are in bold, the rest is by Steve.

Who are you?

I’m 32 years old, have been running Linux since my first year in college back in ’96, and have been a Debian developer now for ten years. Along the way I’ve been involved in maintaining a variety of server packages, worked on the Alpha port for a while, did a stint as a release manager for a couple of years, and serve on the technical committee.

This year I’m also celebrating my ten year anniversary with my lovely wife Patty, who many know as an erstwhile front-desk volunteer at DebConf. God only knows why she puts up with my late-night hacking!

These days in my day job I’m a manager on the Ubuntu Platform team at Canonical, working to help make Ubuntu a daughter distribution that the Debian community can be proud of.

What’s your biggest achievement within Debian or Ubuntu?

There’s no doubt that my biggest achievement in Debian has been overseeing the release of two Debian releases as release manager.

On the other hand, the scope of a release is so huge, and it represents the output of so many developers working together, that it would be arrogant to claim the release itself as an achievement of my own. Also, sarge and etch have long since been rotated off of the mirrors so no one cares about them anymore. 😉 For a more personal and lasting contribution in the distro itself, I’m very proud of writing pam-auth-update. It’s a small piece of code, but one that Debian was missing for a long time – it’s made a big difference to PAM module integration in packages!

What are your plans for Debian Wheezy?

My top priority for this cycle is to see multiarch through. We’re still not far enough along in Debian for most developers to see any difference… and once we are, the first thing people are going to see is a fair bit of breakage when we start breaking a lot of assumptions about paths that have been hard-coded upstream. But I’m still excited by the progress that is being made here. We should be able to ship wheezy without any ia32-libs package. We might even be able to get rid of all the biarch library packages, including those used by the toolchain itself. 54 packages in testing build-depend on gcc-multilib right now, in order to build 32-bit code to ship in the amd64 package; a bunch of those should go away with absolutely no reduction in functionality, saving us a bit of space in the archive and saving the maintainers a lot of complexity in their packages, while at the same time giving us much better support for cross-compilation than we’ve ever had before.

It’s a tall order, certainly, but the pieces are falling into place one by one.

My second priority is to get a policy in Debian around packages integrating upstart jobs. It would of course benefit Ubuntu to have many packages back in sync with Debian, but if all we wanted was to sync with Debian, we could mostly just make debhelper ignore upstart jobs in Debian, prefer them in Ubuntu, and call it good. I’m interested in making sure Debian also gets the benefits of being able to use upstart, because as Linux has become increasingly asynchronous (doing more in parallel at start up), the traditional sysvinit has not been able to keep up. There are all kinds of bugs now related to network startup, for instance, that we don’t have a good answer for in a sysvinit model but that we can fix with an event-based system.

Upstart has been around for a while now, but we’ve been slow to integrate it into Debian because it only works on Linux. It would be a shame if right after the first Debian GNU/kFreeBSD technology preview, packages all stopped working on kFreeBSD because they started to assume the availability of upstart! Unfortunately, having been so cautious we now have systemd on the scene, which not only doesn’t support non-Linux but seems to be in the process of trying to gobble up other, non-Linux-specific components of the desktop stack. So I have to wonder what the future holds for the free desktop on non-Linux kernels.

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

Well, based on my previous experiences when I did spend all my time on Debian, I think the answer here is QA / release work. :) Otherwise, I don’t know. My hands are full enough now with multiarch that it’s hard for me to see what the Next Thing would be.

You’re a member of the technical committee. In the interview of Bdale Garbee, I have argued that it’s not working well. What’s your point of view on this topic?

Well, I feel a constant low level guilt about my own poor level of activity in the TC; but that doesn’t translate into a belief that the system is broken. This is, after all, the decision making body of last resort for technical disputes in Debian, and as such it should really be used sparingly. And if a reputation for glacial deliberation means more developers work out their disputes on their own rather than asking the TC to step in, I think that’s actually a healthy thing!

I do still wish we were more effective at resolving those issues that do come our way, but there’s no silver bullet for this. Though the funny thing is, I’ve noticed that the majority of issues that get referred to the TC nowadays never even need us to make a decision; a short conversation with the disputants is often enough to get them to come to an agreement.

What’s the biggest problem of Debian?

By and large, I think Debian is still doing a great job at what it’s best at — delivering a rock-solid distribution that users can rely on. If I would highlight one problem in Debian, though, it would be that I think we’re becoming less innovative as time goes on. Part of that comes from being such a large project that we’re bound to be more conservative as an institution; but even though the three pet Debian projects of mine that I mentioned above are fairly innovative (multiarch, pam-auth-update, upstart), each of these has landed first in Ubuntu rather than in Debian. Always with a clear intent of pushing back up into Debian, of course, but it just wasn’t possible to do this work within Debian for the first cut without much longer delays.

I worry that if Debian is no longer the place to try new things, that we’re going to miss out on attracting contributions from the folks who are inspired to make Free Software better – and not simply to make it stable.

I’m not sure how to address this, though. Maybe improved conversations with derivatives such as (but not limited to) Ubuntu, about what crack of the day is being tried where and how that can be integrated into Debian once it’s proven to work? I don’t think that team-based maintenance or low-threshold NMUs do anything to address this, though, as the kinds of innovation that matter most are ones that require discussion and consensus-finding — not just routing around inactive maintainers.

Do you have wishes for Debian Wheezy?

Well, I’d like to see the armhf port get on its feet and become an official port. Over the lifetime of the arm and armel ports, the state of the art on ARM has changed quite a bit; it would be great to see Debian taking advantage of this richer platform, to let people make better use of their hardware via Debian.

As a former release manager, you’re now a “release wizard”. I guess you have seen it on debian-devel, there are proposals to not freeze testing and to use another distribution starting as a snapshot of testing to finalize the new stable release. According to your experience, what needs to happen to make this possible?

Frankly, I’ve stayed out of that discussion because I don’t think what’s being asked for is possible. I think proponents of a freezeless release have seriously underestimated the amount of work required on the part of the release team to wrangle testing into a releasable product, and that anything that makes propagation of fixes into the pending release more time consuming will make Debian worse on the whole, not better.

If people really want to avoid long freezes for the Debian release, the best way they can help this happen is by making Debian more releasable on an ongoing basis, by helping to hold our packages to our shared standards for quality (i.e., by fixing RC bugs!). The biggest factor in long freezes for Debian is the slow rate at which we bring the RC bug count down during the freeze. Back in the sarge, etch days we used to have really great bug squashing parties that would get people together on weekends to hack through RC bugs by the dozens. I don’t see that happening as much anymore. I’d really like us to get back to that, but my few attempts at this so far since retiring as release manager have led me to think I’m really terrible at organizing parties of any kind. :)

On the other side, as seen at, the RC bug count for testing at the beginning of the release cycle keeps getting higher and higher. I’d love to know why that is so we can address it. I know we’ve gotten better at detecting some classes of RC bugs; that’s part of it, but I don’t think it explains the whole trend.

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

Wow, what kind of arrogant jerk would I be if I didn’t admire anyone in Debian for their contributions? Debian is and always has been an amazing community of top-notch developers; there are certainly too many I admire to list them all here. Joey Hess certainly makes the list, for his longstanding example of code speaking louder than words and for his ability to get to the heart of common problems and come up with elegant solutions. So does Russ Allbery, who by all accounts had his ability to feel anger in response to email burned out of him at a young age in a flame-related accident on Usenet. 😉 The list goes on, but here I think I have to follow Joey’s example and cut the words short.

Thank you to Steve 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, Twitter and Facebook.

People behind Debian: Meike Reichle, member of Debian Women

Meike Reichle is a Debian developer since 2008 but has been involved for longer than that, in particular in Debian Women. She’s a great speaker and shared her experience in a Debconf talk.

She’s also part of the Debian publicity team and managed the live coverage of the last release on Enough introduction, learn more about her by reading the interview. My questions are in bold, the rest is by Meike.

Who are you?

My name is Meike Reichle, I am a studied information scientist and work as a project manager at Pengutronix, an embedded Linux company probably best known for their ARM kernel work. I live in Germany, more exactly in Lower Saxony, but I was originally born and raised in Swabia. Although I moved here ten years ago I still have a rather strong Swabian cultural identity. (Among other things I pride myself on having introduced a number of fellow DDs to the true promise that are real hand-made Spätzle ;-)) I am married to Alexander Reichle-Schmehl, we’ll have our third wedding anniversary this summer. Apart from Debian most of my spare time is used for all kinds of crafts and DIY activities. Making things with my hands always gives me a great sense of accomplishment.

My Free software history is summed up pretty quickly. Like most women of my age I wasn’t introduced to computers until well into my teens. I didn’t have a computer of my own until I started studying at the university in 2001. From there on things developed rather quickly: Working on the University’s Unix terminals got me hooked on *nixes, so I got me one of those “Linuxes” everyone talked about. I tried a couple of different distributions, ended up with Debian around 2004, started contributing in 2005, and finally became a full DD — what a nice coincidence! — exactly this day (Apr 18th) three years ago.

You’re part of Debian Women. How is the project going? I have the feeling that the number of women involved in Debian has not significantly increased.

The amount of women active within Debian is a tricky thing to judge. Here’s a quick example why:

When the DPL was elected in 2004 there were 911 Debian Developers eligible to vote, 4 of them were female. Shortly after, during DebConf4, debian-women was founded. When the current DPL was reelected last month, there were again 911 Debian Developers eligible to vote, but this time 13 of them were women.

You can look at these numbers and say “The number of female DDs has more than tripled, what a success!” Or you can pull out your calculator and it will tell you that in terms of ratio this puts us from a measly 0.4% to an only slightly less measly 1.4% ratio of female DDs. This still is — pardon my language — a bloody shame, but sadly also pretty close to the average ratio of women in Free Software.

So, while I do think that the debian-women project did already have a significant impact on the Debian project as a whole, I don’t think it has achieved its goals yet. Not for a long time.

There’s still a lot to be done but unfortunately the debian-women project has somewhat run out of steam at the moment. The seven years of its existence divide quite equally into the first half, which was very active and saw great results, and the second half, which was very slow and much more passive. In my impression debian-women is currently undergoing a rather bumpy generational change. On the one hand a lot of the original members, including myself, have reduced their involvement. Speaking for myself this is caused by shift of interests as much as general weariness. On the other hand there are only very few women following up. This development is also reflected quite harshly in DD numbers: If I don’t misjudge any first names (and I desperately hope I do!) for the last three years not a single woman has joined Debian as a developer! After the great start debian-women has had, this is a very painful thing to see!

That said, things don’t look all bad. There is a number of women maintaining packages without being DDs and there’s also at least one woman currently in NM, so there’s hope this standstill won’t last very much longer. But still, the fact remains that debian-women is suffering from a rather serious recruitment problem and I hope that this interview might actually help to spur some new or not yet active members into action. The aim of debian-women is far from achieved and now that its initial members are receding its time for new members to step up and take initiative.

What should Debian do to be more attractive to women ? I think the general atmosphere has improved, we’re less tolerant with rude behaviour, the usual tone on mailing lists has improved. Yet it doesn’t seem to be enough.

If there was a female DD for every time I answered that question…

First of all, I agree, Debian as a community has improved tremendously! Our general tone is much more friendly and cooperative and there is now a much better awareness of the impression we give to outsiders and newcomers.

Now on to the difficult part: The question what should be done to get more women into Free Software has been around almost as long as Free Software exists, and it has been answered very well by a lot of people: Twenty years ago Ellen Spertus wrote Why are There so Few Female Computer Scientists? and most of it still holds true. Almost ten years ago Val Henson (now Aurora) wrote HOWTO Encourage Women in Linux and that also is still pretty accurate. In 2006 Floss Pols undertook extensive research to find out why there were so few women in Open Source and Free Software and how that could be changed. They also came up with a very good set of recommendations. All of these texts highlight different aspects of that question and all of them have very good points.

I personally have, over the years, arrived at a rather sociological, not to say holistic point of view. In fact I answered the exact same question a few days ago, and the answer I gave then was this: “After ~10 years of women in tech advocacy I’d say the ultimate and final measure to get more women into Free Software is by finally achieving a truly equal society and at the same time dramatically improving child care support in almost any country.” I’ve come to the conclusion that what really holds women back in practice is not so much a lack of skill or interest but a simple lack of opportunity. For most of us Free Software is what we do in our spare time and that’s something that women, even today, have considerably less of than men. Even in couples where both partners work full-time it is still mostly the woman who does the majority of the housework and child care duties. In most cultures men have a perceived right to their leisure time that does not to the same degree exist for women.

That is one major reason, the other is instilled modesty, which has kind of become my personal arch-enemy by now. I’ve talked to so many girls and women at all sorts of events about why they won’t take up Computer Science studies or join a Free Software project and the answer I hear most often is that they do not consider themselves “good enough” in one or another aspect. Sometimes they will doubt their technical skills, sometimes their language skills, sometimes their stamina. Needless to say these girls and women were not any less qualified than the people already active in Free Software.

So, yes, in the short and medium term making Debian a more welcoming and friendly place is the way to go. As many others pointed out already this will not only benefit prospective contributors but the community as a whole: those new to it as well as those who’ve been in it for a long time. In the long term however what we need is empowerment! Women who are just as confident about their skills as men and are not discouraged by uncooperative environments. This is of course something that is culturally deep-rooted and can only happen in a very large time frame. So, for the moment the way to go in my view is accessibility: a cooperative atmosphere, a code of conduct, comprehensive documentation not only of technical aspects but also of structures and processes. The other thing we need to do is to have as many already active women as possible attend as many Linux/Debian/Free Software/Whatever events as possible. In my experience it happens quite often that other women see these women, feel very inspired by them, get to talk to them and then a few days later show up on some mailing list or IRC channel. From what I’ve seen personal contact still beats any other kind of “recruiting” measures.

You’re a Debian developer but you’re also married with a Debian developer (Alexander Reichle-Schmehl). Did you meet because of Debian? If not, who introduced Debian to the other one? :-)

We did in fact meet because of Debian. More specifically during our booth shift at the Debian booth at LinuxTag 2005, where I did a talk on the debian-women project and Alex organised the DebianDay. After that our relationship developed pretty much along our Debian activities: After our initial meeting we talked a lot on, when Alex went to DebConf5 and I didn’t we noticed that we kind of missed each other. The first gift he ever gave me was a Debconf5 shirt and a box Finnish chocolates (I still have one of them today. :)) Our first secret kiss was at ApacheCon 2005, where we were both staffing the Debian booth (kudos to abe for pretending not to notice). We then became an “official couple” at Berlinux 2005 where we were both staffing the Debian booth and giving talks on packaging and user motivation. Our first real relationship stress test was when we both joined the DebConf6 orga team. It was a stressful time, but we passed it with flying colours! About a year later we announced our engagement via Our wedding was a veritable MiniDebConf, one of the best gifts we got was a Debian cookbook including the favourite recipes of DDs from around the world.

By now we’ve both finished university and work full-time jobs, so we don’t do as many talks and attend as many Debian events as we used to. Instead we now mainly focus on press and publicity work, which is quite practical to work on as a pair. It’s actually rather funny that way, Alex and I get confused with each other quite often, since we have almost the same name, often pick up on each other’s E-Mail conversations and are most often quoted by our function rather than by name. Because of we have kind of merged into this virtual Debian Press Person in the perception of many of our contacts.

You also have another “hat”: Debian Press Officer. What is this about? What would you suggest to people who would like get involved in that domain?

Debian press work is mainly about providing an official and coordinated point of contact to anyone wanting information from or about Debian. The press team answers all sorts of inquiries (the most popular one is is of course always the next release date) and makes sure all important events and developments within Debian receive the attention and recognition they deserve. Debian is a diverse project where every sort of contributor is free to voice his or her opinion in any way. We don’t have NDAs or prescribed terminology. That’s one of the things I love about Debian but also something that makes us difficult to handle for conventional media. They want official statements, in generally understandable terms, at appointed times. That’s what the press team takes care of. Almost all of the press work is done in the publicity team, which coordinates using IRC, Mail and SVN. The publicity team also publishes the Debian Project News, which are very popular among our users and developers. Press work is also an area of work that offers lots of possibilities for non-technical contribution. lists a number of possibilities for contribution and, like most Debian Teams, we’d be more than grateful to get some more helping hands and happy to introduce interested newcomers to our work.

What’s the biggest problem of Debian?

In my view: Overwork. Debian has thousands of contributors but still a lot of the main work rests on very few shoulders. We need more contributors, especially, but not only in the key teams. In order to get more people we need to do some marketing which is very hard for us, since we are very proud of our independence and have a strong focus on purely technical aspects rather than aiming for popularity. However, with the current amount of Open Source and Free Software projects to join we find ourselves not only in a contest on technical excellence but also a sort of popularity contest that is about perception rather than hard facts. This popularity contest is difficult for Debian and currently costs us quite a bunch of very capable people.

Do you have wishes for Debian Wheezy?

My answer to that is a non-technical one: I think Debian is currently very under-appreciated, we do a lot of great work and maybe even more importantly we do a lot of important work for Software Freedom, sometimes even at the cost of our above-mentioned popularity. I hope people will appreciate that more again in the future.

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

Over the years I have made a lot of friends within the Debian community, some have even become family. That makes it somewhat hard to single out individual people. I think what I admire most is continuous commitment. I am very impressed by those among us who have kept up a high level of commitment over many years and at the same time managed to bring that in line with a fulfilled personal/family life. That’s something that I hope I’ll also be able to achieve in the years to come.

Thank you to Meike for the time spent answering my questions. I hope you enjoyed reading her 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, Twitter and Facebook.

People behind Debian: Adam D. Barratt, release manager

Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now “Release manager”, a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen.

You could expect the release managers to have some rest after a big release, but it’s not really the case. With the long freeze, loads of “transitions” have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions.

He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam.

Who are you?

I’m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf.

As well as being on the release team, I’m a member of the maintainer teams for devscripts and lintian.

Can you describe your journey in Debian and in the release team?

I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels.

When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I’d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9.

As most readers will be aware, we unfortunately reached a point during last year where we didn’t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say…

How much time do you usually spend working for the release team ?

I’ve been trying to work out how to usefully answer this question. My initial answer was “approximately two hours each day”, but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I’ve decided to stick with my initial answer.

During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I’m reliably informed that at that point the correct answer to the question is “too much time”. :-)

What’s your own retrospective of the Squeeze release? What went well and what needs to be improved?

Overall, I believe the release went well and that we should all be proud of the Squeeze release. The parts of the release cycle which highlighted the need for improvement all share, imo, a single root cause – communication, particularly around freeze-related plans. We worked hard during the freeze itself to improve our communication with the rest of the project and want to continue in that vein during the Wheezy cycle.

One thing that I personally found quite difficult at times before the freeze was keeping track of the transitions which were still waiting for a place in the queue; it’s also something that we could improve on at this early stage of the Wheezy cycle. In order to help us keep a clear overview of requests for transitions, stable updates and binNMUs, it would be helpful if they could be filed as appropriately user-tagged bugs. This not only allows us to easily get an overview of the status of requests from the BTS but also aids transparency by allowing anyone else to do so; as a useful additional feature, it means that we can use the BTS’s blocking functionality to indicate reasons why a request cannot be fulfilled right now.

Are you in favor of time based freeze?

I think there’s merit in having a time frame that we can work towards in order to achieve the goals which we set ourselves for the release, as individual maintainers, maintenance teams and a project. I do have concerns that even with such a time frame in place there will still be uploads made very close to the proposed freeze point and transitions which may be unfinished, for example because of an unforeseen entanglement with or reliance on the transition of another package.

One thing I’m interested in is how exact and specific that time frame should be and the balance between predictability and being able to achieve everything we want for a great release; this is something we can cover in the debate on this subject which I know many people have strong opinions about.

What are your plans for Debian Wheezy?

The Wheezy to-do list I started before the final Squeeze release begins “multiarch, multiarch, multiarch”. It looks like we’re finally going to get that achieved during this release cycle, thanks to a great deal of hard work from various people. I’m also interested in seeing the C.UTF-8 locale standardised throughout Debian and continuing to work on our tools and processes to make tracking of transitions and stable updates simpler (or at least appearing to be so :-) and more transparent.

With my package maintenance hats on, I’d like to help ensure that both devscripts and lintian are able to keep pace with changes in the development landscape in Debian (e.g. more useful package diffing for source format v3 packages) and continue to be tools that are an integral part of package development in Debian.

Some people (including me) would like a rolling distribution constantly usable by end-users. Do you think that the release process currently geared towards producing “stable” can be accommodated to support this?

I’m not yet convinced that the concept of a rolling, “constantly usable” distribution can be easily integrated in to the workflow that exists around preparing stable releases in Debian. The “testing” distribution was created as, and continues to be used as, a tool to enable the release team to create the next stable release – that it happens to be something that people can use every day for much of the time is mostly a happy side-effect of the fact that we don’t gratuitously break it, but is by no means guaranteed to be the case early in the release cycle or during large, disruptive, transitions.

It’s been suggested that “testing” and “rolling” could be basically the same for most of the cycle, with “rolling” then continuing to be updated when testing is frozen. This would essentially mean an extra suite which is only used for a few months every couple of years or so, which is one of the things that “testing” was intended to avoid (i.e. the old “frozen” suite) and seems like a lot of overhead to introduce in order to reduce disruption to some users during the freeze. The early part of the release cycle also tends to include a number of larger transitions which often require packages to either be removed from testing or broken as part of migrating the transition, if they are not able to be successfully updated in time.

What’s the biggest problem of Debian?

The thing that I’ve been noticing myself becoming frustrated by recently is a tendency to debate the minor details of proposals, rather than concentrating on getting the key points right to begin with. Clearly for some projects such as multiarch the details may be as important as the big picture, but in most cases the people working on a development should be allowed to look after the smaller details themselves.

That’s not meant to imply that feedback from other parts of the project should not be welcomed, simply that if we consider Debian to be a “do-ocracy” then we need to permit people the freedom to “do”.

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

All previous release managers, for making the job look much easier than it seems when you’re in the “hot seat”. :-)

Outside of the release team, Joey Hess for his contributions to various parts of the Debian development environment over the years, such as debhelper and debian-installer, and Colin Watson for his enviable willingness to tackle a wide variety of different projects within Debian.

Thank you to Adam 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, Twitter and Facebook.

People behind Debian: Bdale Garbee, chair of the technical committee

Bdale is a long-time Free Software believer, he has been contributing even before Debian existed… in the prehistoric era of free software. :-)

Anyone who went to a big Free Software conference has seen one of his colorful t-shirts. Or maybe you have heard the story where he got his beard shaved by Linus Torvalds to raise funds to protect the Tasmanian Devil.

More seriously Bdale has played and continue to play a number of important roles in the Debian community. He also represents one of the biggest corporate sponsors (both for DebConf and for the servers that Debian owns): Hewlett Packard.

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

Who are you?

I made my first personal contribution of source code to what we now call Free Software in 1979. I started with HP in 1986 and for nearly a decade have served the company as Chief Technologist for Open Source & Linux. I am president of Software in the Public Interest, which is the “umbrella organization” providing legal and financial existence for Debian in the USA. I also represent users, developers, and Debian interests on a number of boards including at the Linux Foundation and the Freedombox Foundation.

I’m happily married with two children. Many people in Debian have met some or all of my family. They all joined me for Debconf in Edinburgh, and my daughter Elizabeth also attended in Caceres and New York.

I joined Debian in 1994. I’ve been responsible for a number of packages essential to our base system continuously since that time. But I’ve also contributed to the project in many other ways over the years. I ran the first server that was fully dedicated to Debian. Ideas of mine influenced the development of project infrastructure, from the early design of our mirror network to structuring the archive around a ‘package pool’. I started or made significant early contributions to 5 ports of Debian to non-i386 architectures. I served as Debian Project Leader (DPL) in 2002-2003, was acting Secretary for a while, and have served on the Technical Committee for a number of years.

Over the years, I’ve also had some interesting hobbies. I helped design, build, and program pieces of various amateur radio satellites. I enjoy making physical things, and have many tools for working in wood and metals. My son and I are very active in the world of high power model rockets. And with my partner (and fellow Debian developer!) Keith Packard I’m now running a small business making and selling open hardware and open source avionics for hobby rockets. You can read more about that at

You’re the chair of the Debian technical committee. Can you quickly explain the role of this committee?

I think many people assume the Technical Committee has a larger role in Debian than it really does. Section 6 of Debian’s constitution defines the official role of the Technical Committee. Most importantly, the committee exists as a last resort place to resolve technical conflicts between Debian developers that they are unable to resolve by themselves. Most of the power in Debian is left in the hands of individual developers, who are usually able to collaborate with each other to make good technical decisions. So the Technical Committee’s resolution process has only rarely been needed, which I think is a very good thing.

From my point of view, the technical committee is not working. In many cases, the committee does not take any (timely) decision and just waits until the underlying situation has evolved to a point where the intervention of the committee is no longer needed. Do you agree with this and how can you explain it?

I think it’s very important for all of us to remember that everyone working on Debian does so voluntarily, and people who volunteer their time generally deserve a measure of respect and appreciation for their efforts.

No issue is brought to the Technical Committee unless resolving it is expected to be really difficult, or at least contentious. And often, the issues brought to the committee have been as much or more about personality than technology. That makes some of them really hard to solve.

So I do not agree that the technical committee is not working. It seems to me that the decisions that bog down and take a long time are the ones where arguments start out or become emotional instead of technical. In this context, if committee members can help lead public and private discussions in a way that causes a situation to evolve to the point where a decision is no longer needed, that may be healthier for the project in the long term than a quick vote that satisfies some contributors at the expense of others.

The last important change that was made to try to revive the committee was the addition of two new members (Don Armstrong and Russ Allbery). Is there anything else that could be tried?

The biggest improvement I could personally wish for is something people sending issues to the committee can help with. As the ultimate technical decision making body for a project whose output is mostly software, the more a request can be put in terms of a decision about source code, the easier it will be for us to make a decision. That won’t always be possible, but when we’re forced to try and dream up alternatives and then figure out whether anyone would actually be willing to write the code to implement those alternatives, the process takes a lot longer than choosing between competing patch sets or deciding whether a patch should be included.

Besides your role in the technical committee, you have held the role of mediator/facilitator/advisor on numerous occasions. Because you’re an old wise bearded guy who travels a lot and knows many Debian contributors… I would like to thank you for all this work that few people notice. Are there been times where this has been a real burden for you?

Thank you for mentioning this. I’ve put a lot of my heart into Debian over the years, largely because it’s a project and a community that continues to amaze and inspire me.

I feel fortunate to have been able to meet and work on Debian with so many outstanding people from around the world. Many are now my friends, with all the silly and serious things being a friend implies. I’ve been asked for and have given advice many times. I’ve helped celebrate birthdays, marriages, new jobs, and the arrival of children. Sadly, I have also found myself having to try and find the right words to mark the loss of some of these friends…

The only time any of this feels like a burden is when there’s some important problem that many people care about, that I’m working “behind the scenes” to help fix, but can’t really talk about publicly without causing more harm than good. It’s distressing to have people think you don’t care or aren’t helping, when really you’re doing everything you possibly can… just not in a publicly visible way. Of course I understand that this is an impossible situation. If you can’t see what’s happening, there’s no way to know if something is happening or not. That’s why I advocate doing as much as possible in Debian, and SPI, and everywhere else I contribute in as open a way as possible.

You have been Debian Project Leader and you promoted the vision of Debian as the Universal Operating System. What does “universal” mean for you?

The biggest thing to me at the time was the idea that Debian could be anything. Those who chose to work on Debian would ultimately determine what Debian became. I also wanted to make sure we thought about as broad a set of potential users and collaborators as possible.

But this vision provided a framework for pursuing a whole range of worthwhile increases in Debian’s scope of utility, some of which I articulated in my DPL platforms, some others put forward. Internationalization, porting to more supported architectures, our inclusive and evolving approaches to accepting new developers and new packages, and so forth.

I think this vision has served us well, and it pleases me that it has stayed a part of our collective thinking for so long.

We’re again in Debian’s electoral period, what do you think of the work done by the current DPL?

I’m very happy with what I’ve observed of Stefano’s activities during his first year as DPL. He has an obvious enthusiasm for Debian, communicates well both in one to one interactions and in front of a crowd, and I think represents Debian very well.

It is interesting that he’s running unopposed for re-election this year. I choose to interpret that as evidence he’s doing a good job, the project is running well, and nobody feels the need to try and take the job away From him. I’m glad he’s willing to continue in this role for another year.

What’s the most important thing that Debian should achieve in the wheezy timeframe?

I don’t yet have a very crisp personal wish-list for wheezy. But I would certainly like to see multiarch support finally completed! I’m also very interested to see what comes from the CUT work.

You have been an early supporter of “multiarch”, a project to allow easy installation of foreign architecture packages. It’s on good track for Wheezy. Do you think it’s an important milestone?

My original motivation for requesting multiarch support was to enable support for 32-bit x86 binaries on ia64 “Itanium” systems, in the time leading up to the “sarge” release. I ended up creating the ia32-libs package, which I’m not proud of. The emergence of 64-bit extensions to x86 (the amd64 architecture) made this a much broader issue. Today, I run a 64 bit kernel and a 32 bit user space on my notebook. There are problems with just moving entirely to 64 bit… but I would like to be able to run some applications that work with large data sets in full 64 bit mode!

Thank you to Bdale Garbee 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, Twitter and Facebook.

People behind Debian: Christian Perrier, translation coordinator

Christian is a figure of Debian, not only because of the tremendous coordination work that he does within the translation project, but also because he’s very involved at the social level. He’s probably in the top 5 of the persons who attended most often the Debian conference.

Christian is a friend (thanks for hosting me so many times when I come to Paris for Debian related events) and I’m glad that he accepted to be interviewed. He likes to speak and that shows in the length of his answers… :-) but you’ll be traveling the world while reading him.

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

Who are you?

I am a French citizen (which is easy to guess unless you correct my usual mistakes in what follows). I’m immensely proud of being married for nearly 26 years with Elizabeth (who deserves a statue from Debian for being so patient with my passion and my dedication to the project).

I’m also the proud father of 3 wonderful “kids”, aged 19 to 23.

I work as team manager in the Networks and Computers Division of Onera “the French Aerospace lab”, a public research institute about Aeronautics, Space and Defense. My team provides computer management services for research divisions of Onera, with a specific focus put on individual computing.

I entered the world of free software as one of the very first users of Linux in France. Back in the early 1990’s, I happened (though the BBS users communities) to be a friend of several early adopters of Linux and/or BSD386/FreeBSD/NetBSD in France. More specifically, I discovered Linux thanks with my friend René Cougnenc (all my free software talks are dedicated to René, who passed away in 1996).

You’re not a programmer, not even a packager. How did you come to Debian?

I’m definitely not a programmer and I never studied computing (I graduated in Materials Science and worked in that area for a few years after my PhD).

However, my daily work always involved computing (I redesigned the creep testing laboratory and its acquisition system all by myself during my thesis research work). An my hobbies often involved “playing” with home computers, always trying to learn about something new.

So, first learning about a new operating system…then trying to figure out how to become involved in its development was quite a logical choice.

Debian is my distro of choice since it exists. I used Slackware on work machines for a while, but my home server, kheops, first ran Debian 1.1 when I stopped running a BBS on an MS-DOS machine to host a news server. That was back in October 1996.

I then happened to be a user, and more specifically a user of genealogy software, also participating very actively in Usenet…from this home computer and server, that was running this Debian thing.

So, progressively, I joined mailing lists and, being a passionate person, I tried to figure out how I could bring my own little contribution to all this.

This is why I became a packager (yes, I am one!) by taking over the “geneweb” package, which I was using to publish my genealogy research. I applied as DD in January 2001, then got my account in July 2001. My first upload to the Debian archive occurred on August 22nd 2001: that was of course geneweb, which I still maintain.

Quite quickly, I became involved in the work on French localization. I have always been a strong supporter of localized software (I even translated a few BBS software back in the early 90’s) as one of the way to bring the power and richness of free software to more users.

Localization work lead me to work on the early version of Debian Installer, during those 2003-2005 years where the development of D-I was an incredibly motivating and challenging task, lead by Joey Hess and his inspiring ideas.

From user to contributor to leader, I suddenly discovered, around 2004, that I became the “coordinator” of D-I i18n (internationalization) without even noticing… :-)

You’re the main translation coordinator in Debian. What plans and goals have you set for Debian Wheezy?

As always: paint the world in red.

Indeed, this is my goal for years. I would like our favorite distro to be able to be used by anyone in the world, whether she speaks English, Northern Sami, Wolof, Uyghur or Secwepemctsín.

As a matter of symbol, I use the installer for this. My stance is that one should be able to even install Debian in one’s own language. So, for about 7 years, I use D-I as a way to “attract” new localization contributors.

This progress is represented on this page where the world is gradually painted in red as long as the installer supports more languages release after release. The map above tries to illustrate this by painting in red countries when the most spoken language in the country is supported in Debian Installer.

However, that map does not give enough reward to many great efforts made to support very different kind of languages. Not only various “national” languages, but also very different ones: all regional languages of Spain, many of the most spoken languages in India, minority languages such as Uyghur for which an effort is starting, Northern Sami because it is taught in a few schools in Norway, etc., etc.

Still, the map gives a good idea of what I would like to see better supported: languages from Africa, several languages in Central Asia. And, as a very very personal goal, I’m eagerly waiting for support of Tibetan in Debian Installer, the same way we support its “sister” language, Dzongkha from Bhutan.

For this to happen, we have to make contribution to localization as easy as possible. The very distributed nature of Debian development makes this a challenge, as material to translate (D-I components, debconf screens, native packages, packages descriptions, website, documentation) is very widely spread.

A goal, for years, is to set a centralized place where translators could work easily without even knowing about SVN/GIT/BZR or having to report bugs to send their work. The point, however, would be to have this without making compromises on translation quality. So, with peer review, use of thesaurus and translation memory and all such techniques.

Tools for this exist: we, for instance, worked with the developers of Pootle to help making it able to cope with the huge amount of material in Debian (think about packages descriptions translations). However, as of now, the glue between such tools and the raw material (that often lies in packages) didn’t come.

So, currently, translation work in Debian requires a great knowledge of how things are organized, where is the material, how it can be possible to make contribution reach packages, etc.

And, as I’m technically unable to fulfill the goal of building the infrastructure, I’m fulfilling that role of spreading out the knowledge. This is how I can define my “coordinator” role.

Ubuntu uses a web-based tool to make it easy to contribute translations directly in Launchpad. At some point you asked Canonical to make it free software. Launchpad has been freed in the mean time. Have you (re)considered using it?

Why not? After all, it more or less fills in the needs I just described. I still don’t really figure out how we could have all Debian material gathered in Rosetta/Launchpad….and also how Debian packagers could easily get localized material back from the framework without changing their development processes.

I have always tried to stay neutral wrt Ubuntu. As many people now in Debian, I feel like we have reached a good way to achieve our mutual development. When it comes at localization work, the early days where the “everything in Rosetta and translates who wants” stanza did a lot of harm to several upstream localization projects…is, I think, way over.

Many people who currently contribute to D-I localization were indeed sent to me by Ubuntu contributors….and by localizing D-I, apt, debconf, package descriptions, etc., they’re doing translation work for Ubuntu as well as for Debian.

Let’s say I’m a Debian user and I want to help translate Debian in my language. I can spend 1 hour per week on this activity. What should I do to start?

Several language teams use Debian mailing lists to coordinate their work. If you’re lucky enough to be a speaker of one of these languages, try joining debian-l10n-<yourlanguage> and follow what’s happening there. Don’t try to immediately jump in some translation work. First, participate to peer reviews: comment on others’ translations. Learn about the team’s processes, jargon and habits.

Then, progressively, start working on a few translations: you may want to start with translations of debconf templates: they are short, often easy to do. That’s perfect if you have few time.

If no language team exists for your language, try joining debian-i18n and ask about existing effort for your language. I may be able to point you to individuals working on Debian translations (very often along with other free software translation efforts). If I am not, then you have just been named “coordinator” for your language… :-) I may even ask you if you want to work on translating the Debian Installer.

What’s the biggest problem of Debian?

We have no problems, we only have solutions… :-)

We are maybe facing a growth problem for a few years. Despite the increased “welcoming” aspects of our processes (Debian Maintainers), Debian is having hard times in growing. The overall number of active contributors is probably stagnating for quite a while. I’m still amazed, however, to see how we can cope with that and still be able to release over the years. So, after all, this is maybe not a problem… :-)

Many people would point “communication problems” here. I don’t. I think that communication inside the Debian project is working fairly well now. Our “famous” flame wars do of course still happen from time to time, but what large free software project doesn’t have flame wars?

In many areas, we indeed improved communication very significantly. I want to take as an example the way the release of squeeze has been managed. I think that the release team did, even more this time, a very significant and visible effort to communicate with the entire project. And the release of squeeze has been a great success in that matter.

So, there’s nearly nothing that frustrates me in Debian. Even when a random developer breaks my beloved 100% completeness of French translations, I’m not frustrated for more than 2 minutes.

You’re known in the Debian community as the organizer of the “Cheese & Wine Party” during DebConf. Can you tell us what this is about?

This is an interesting story about how things build themselves in Debian.

It all started in July 2005, before DebConf 5 in Helsinki. Denis Barbier, Nicolas François and myself agreed to bring at Debconf a few pieces of French cheese as well as 1 or 2 bottles of French wine… and share them with some friends. Thus, we settled an informal meeting in “the French room” where we invited some fellows: from memory, Benjamin “Mako” Hill, Hannah Wallach, Matt Zimmermann and Moray Allan. All of us fond of smelly cheese, great wine… plus some extra “pâté” home-made by Denis in Toulouse.

It finally happened that, by word of mouth, a few dozens of other people slowly joined in that French room and turned the whole thing into an improvized party that more or less lasted for the entire night.

The tradition was later firmly settled in 2006, first in Debconf 6 in Mexico where I challenged the French DDs to bring as many great cheese as possible, then during the Debian i18n meeting in Extremadura (Sept 2006) where we reached the highest amount of “cheese per participant” ever. I think that the Creofonte building in Casar de Cáceres hasn’t fully recovered from it and is still smelling cheese 5 years after.

This “party” later became a real tradition for DebConf, growing over and over each year. I see it as a wonderful way to illustrate the diversity we have in Debian, as well as the mutual enrichment we always felt during DebConfs.

My only “regret” about it is that it became so big over the years that organizing it is always a challenge and I more and more feel pressure to make it successful. However, over the years, I always found incredible help by DebConf participants (including my own son, last year… a moment of sharing which we will both remember for years, i think). And, really, in 2010, standing up on a chair, shouting (because the microphone wasn’t working) to thank everybody, was the most emotional moment I had at Debconf 10.

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

So many people. So, just like it happens in many awards ceremonies, I will be very verbose to thank people, sorry in advance for this.

The name that comes first is Joey Hess. Joey is someone who has a unique way to perceive what improvements are good for Debian… and a very precise and meticulous way to design these improvements. Think about debconf. It is designed for so long now and still reaching its very specific goal. So well designed that it is the entire basis for Joey’s other achievement: designing D-I. Moreover, I not only admire Joey for his technical work, but also for his interaction with others. He is not he loudest person around, he doesn’t have to….just giving his point in discussion and, guess what? Most of the time, he’s right.

Someone I would like to name here, also, is Colin Watson. Colin is also someone I worked with for years (the D-I effect, again…) and, here again, the very clever way he works on technical improvements as well as his very friendly way to interact with others…just make it.

And, how about you, Raphaël? :-) I’m really admirative of the way you work on promoting technical work on Debian. Your natural ability to explain things (as good in English as it is in French) and your motivation to share your knowledge are a great benefit for the project. Not to mention the technical achievements you made with Guillem on dpkg of course!

Another person I’d like to name here is Steve Langasek. We both maintain samba packages for years and collaboration with him has always been a pleasure. Just like Colin, Steve is IMHO a model to follow when it comes at people who work for Canonical while continuing their involvment in Debian. And, indeed, Steve is so patient with my mistakes and stupid questions in samba packaging that he deserves a statue.

We’re now reaching the end of the year where Stefano Zacchiroli was the Debian Project Leader. And, no offense intended to people who were DPL before him (all of them being people I consider to be friends of mine), I think he did the best term ever. Zack is wonderful in sharing his enthusiasm about Debian and has a unique way to do it. Up to the very end of his term, he has always been working on various aspects of the project and my only hope is that he’ll run again (however, I would very well understand that he wants to go back to his hacking activities!). Hat off, Zack!

I again have several other people to name in this “Bubulle hall of Fame”: Don Armstrong, for his constant work on improving Debian BTS, Margarita Manterola as one of the best successes of Debian Women (and the most geeky honeymoon ever), Denis Barbier and Nicolas François because i18n need really skilled people, Cyril Brulebois and Julien Cristau who kept packaging alive in lenny and squeeze, Otavio Salvador who never gave up on D-I…even when we were so few to care about it.

I would like to make a special mention for Frans Pop. His loss in 2010 has been a shock for many of us, and particularly me. Frans and I had a similar history in Debian, both mostly working on so-called “non technical” duties. Frans has been the best release manager for D-I (no offense intended, at all, to Joey or Otavio….I know that both of them share this feeling with me). His very high involvment in his work and the very meticulous way he was doing it lead to great achievements in the installer. The Installation Guide work was also a model and indeed a great example of “non technical work” that requires as many skills as more classical technical work. So, and even though he was sometimes so picky and, I have to admit, annoying, that explains why I’m still feeling sad and, in some way, guilty about Frans’ loss.

One of my goals for wheezy is indeed to complete some things Frans left unachieved. I just found one in bug #564441: I will make this work reach the archive, benefit our users and I know that Frans would have liked that.

Thank you to Christian 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, Twitter and Facebook.