Interview – Page 5

People behind Debian: Adam D. Barratt, release manager

April 7, 2011 by Raphaël Hertzog

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

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

March 28, 2011 by Raphaël Hertzog

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 http://altusmetrum.org.

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

People behind Debian: Christian Perrier, translation coordinator

March 3, 2011 by Raphaël Hertzog

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 X.org 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 Identi.ca, Twitter and Facebook.

People behind Debian: Maximilian Attems, member of the kernel team

February 17, 2011 by Raphaël Hertzog

Maximilian, along with the other members of the Debian kernel team, has the overwhelming job of maintaining the Linux kernel in Debian. It’s one of the largest package and certainly one where dealing with bug reports is really difficult as most of them are hardware-specific, and thus difficult to reproduce.

He’s very enthusiastic and energetic, and does not fear criticizing when something doesn’t please him. You’ll see.

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

Who are you?

My name is Maximilian Attems. I am a theoretical physicist in my last year of PhD at the Technical University of Vienna. My main research area is the early phase of a Quark-Gluon Plasma as produced in heavy ion collisions at the LHC at CERN. I am developing simulations that take weeks on the Vienna Scientific Cluster (in the TOP 500 list). The rest of the lab is much less fancy and boils down to straight intel boxes without any binary blobs or external drivers (although lately we add radeon graphics for decent free 3D). Mathematica and Maple are the rare exceptions to the many dev tools of Debian (LaTeX, editors, git, IDE’s, Open MPI, ..) found at the institute, as those are unfortunately yet unmatched in Free Software for symbolic computations. The lab mostly runs a combination of Debian stable (testing starting from freeze) for desktops and oldstable/stable for servers. Debian is in use for more than 10 years. So people in the institute know some ups and downs of the project. Newcomers like my room neighbors are always surprised how functional a free Debian Desktop is. 🙂

What’s your biggest achievement within Debian?

Building lots and lots of kernels together with an growing uptake of the officially released linux images.

I joined the Debian kernel team shortly after Herbert Xu departed. I had been upstream Maintainer of the linux-2.6 janitor project for almost a year brewing hundreds of small cleanups with quilt in a tree named kjt for early linux-2.6. In Debian we had lots of fun in sorting out the troubles that the long 2.5 freeze had imposed: Meaning we were sitting on a huge diverging “monolithic” semi-good patchset. It was great fun to prepare 2.6.8 for Sarge with a huge team enthusiastic in shipping something real close to mainline (You have to imagine that back then you had no stable or longterm release nor any useful free tools like git. This involved passing patches around, hand editing them and seeing what the result does.)

From the Sarge install reports a common pattern emerged that the current Debian early userspace was causing lots of boot failures. This motivated me to develop an alternative using the new upstream initramfs features. So I got involved in early userspace. Thanks to large and active development team initramfs-tools got a nice ecosystem. It still tries to be as generic and flexible as possible and thus gains many nice features. Also H. Peter Anvin (hpa) gave me the official co-maintenance of klibc. klibc saw uptake and good patches from Google in the last 2 years. I am proud that the early userspace is working out fairly well these days, meaning you can shuffle discs around and see your box boot.

Later on we focused on 2.6.18 for Etch, which turned out to a be good release and picked up by several other distributions. Only very much later we would see such a “sync” again. With 2.6.26 for Lenny we got somehow unlucky as we just missed the new longterm release by one release. We also pushed for another update very late (during freeze) in the release cycle, which turned out to semi-work as too much things depend on linux-2.6.

For Squeeze 2.6.32 got picked thanks to discussions at Portland Linux Plumbers and it turned out to be a good release picked up by many distributions and external patchsets. The long-term support is going very well. Greg KH is doing a great job in collecting various needed fixes for it. Somehow we had hoped that the Squeeze freeze would start sooner and that the freeze duration would be shorter, since we were ready for a release starting from the actual freeze on. The only real big bastard on the cool 2.6.32 “sync” is Red Hat. Red Hat Enterprise 6.0 is shipping the linux-2.6 2.6.32 in obfuscated form. They released their linux-2.6 as one big tarball clashing with the spirit of the GPL. One can only mildly guess from the changelog which patches get applied. This is in sharp contrast to any previous Red Hat release and has not yet generated the sharp and snide comments in press it deserves. Red Hat should really step back and not make such stupid management moves. Next to them even the semi-maintained Oracle “Unbreakable” 2.6.32 branch looks better: It is git fetchable.

What are your plans and those of the kernel team for Debian Wheezy?

Since 2.6.32 many of the used patches landed upstream or are on the way (speakup, Kbuild Debian specific targets, ..). The proper vfs based unionfs is something we’d be looking forward. We haven’t yet picked the next upstream release we will base Wheezy on, so currently we can happily jump to the most recent ones. There are plans for better interaction with Debian Installer thanks to generating our udebs properly in linux-2.6 source itself. Also we are looking forward to using git as tool of maintenance. We’d hope that this will also allow for even better cross distribution collaboration.

Concerning early userspace I plan to release an initramfs-tools with more generic userspace for the default case and finally also a klibc only for embedded or tuning cases.

What do you like most in Debian?

For one thing I do like the 2 year release cycle. It is not too long to have completely outdated software and on the other hand it gives enough time to really see huge progress from release to release. Also at my institute the software is is recent enough without too much admin overhead. For servers the three years support are a bit short, but on the manageable side.

I do enjoy a lot the testing distribution. For my personal use it is very stable and thus I mainly run testing on my desktop and work boxes. (Occasionally mixing in things from sid for unbreaking transition or newer security fixes).

Debian is independent and not a commercial entity. I think this is its main force and even more important these days. I enjoy using the Debian platform a lot at work thus in return this motivates me to contribute to Debian itself. I also like the fact that we strive for technical correctness.

Is there some recurrent problem that hinders the progress of Debian?

The “New Maintainer process” is a strange way to discourage people to contribute to Debian. It is particularly bureaucratic and a huge waste of time both for the applicant and his manager. It should be completely thrown overboard.

One needs a more scalable approach for trust and credibility that also enhances the technical knowledge for coding and packaging of the applicant.

NM is currently set in stone as any outside critics is automatically rejected. Young and energetic people are crucial for Debian and the long-term viability of the project, this is the reason why I’d consider the “New Maintainer process” as Debian’s biggest problem.

Note from Raphaël Hertzog: I must say I do not share this point of view on the New Maintainer process, I have witnessed lots of improvements lately thanks to the addition of the Debian Maintainer status, and to the fact that a good history of contribution can easily subsume the annoying Tasks & Skills questionnaire.

Another thing I miss is professional graphics’ input both for the desktop theme and the website. I know that effort has been done there lately and it is good to see movement there, but the end result is still lacking.

Another trouble of Debian is its marketing capabilities. It should learn to better sell itself. It is the distribution users want to run and use—not the rebranded copies of itself with lock-in “sugar”. Debian is about choice and it offers plenty of it: it is a great default Desktop.

Linus Torvalds doesn’t find Debian (and/or Ubuntu) a good platform to hack on the kernel. Do you know why and what can we do about this?

The Fedora linux-2.6 receives contributions from several Red Hat employed upstream sub-Maintainers. Thus it typically carries huge patches which are not yet upstream. As a consequence eventual userland troubles get revealed quite quickly and are often seen there first. The cutting edge nature of Fedora rawhide is appealing for many developers.

The usual Debian package division of library development files and the library itself is traditionally an entry barrier for dev on Debian. Debian got pretty easily usable these days, although we could and should again improve a lot more in this sector. Personally I think that Linus hasn’t tried Debian for years.

I have the feeling that the implication of the Debian Kernel team in LKML has been on the rise. Is that true and how do you explain this?

Ben Hutchings is the Nr.1 contributor for 2.6.33. He also is top listed as author of patches on stable 2.6.32. Debian is not listed as organization as many send their linux-2.6 patches from their corporate or personal email address and thus it won’t be attributed to Debian.

There is currently no means to see how many patches get forwarded for the stable tree, but I certainly forwarded more then fifty patches. I was very happy when Greg KH personally thanked me in the 2.6.32.12 release.

In the Squeeze kernel, the firmwares have been stripped and moved into separate packages in the non-free section. What should a user do to ensure his system keeps working?

There is a debconf warning on linux-2.6 installation. It is quite clear that the free linux-2.6 can’t depend on the firmware of the non-free archive (also there is no strict dependency there technically).

On the terminal you’d also see warnings by update-initramfs on the initramfs generation for drivers included in the initramfs.

The debconf warning lists the filename(s) of the missing firmware(s). One can then “apt-cache search” for the firmware package name and install it via the non-free repository. The check runs against the current loaded modules. The match is not 100% accurate for special cases as the one where the device might be handled well by this driver without firmware, but is accurate enough to warrant the warning.

The set of virtualization technologies that the official Debian kernel supports seems to change regularly. Which of the currently available options would you recommend to users who want to build on something that will last?

KVM has been a smooth ride from day zero. It almost got included instantly upstream. The uptake it has is great as it sees both dev from Intel and AMD. Together with libvirt it’s management is easy. Also the performance of virtio is very good.

The linux containers are the thing we are looking forward for enhanced chroots in the Wheezy schedule. They are also manageable by libvirt.

Xen being the “bad outside boy” has an incredible shrinking patchset, thus is fair to expect to see it for Wheezy and beyond. For many it may come a bit late, but for old hardware without relevant CPU it is there.

Many tend to overstate the importance of the virtualization tech. I’d be much more looking forward to the better Desktop support in newer linux-2.6. The Desktop is important for linux and something that is in heavy use. The much better graphics support of the radeon and nouveau drivers:

For Nouveau in 32 with 33 drm we could only deliver a first taste meaning something better then rusty nv.
For Radeon the support for Evergreen and newer is only been shaping now.

The performance optimizations thanks to dcache scalability work and the neat automatic task-grouping for the CPU scheduler are very promising features for the usability of the linux desktop. Another nice to have feature is the online defrag of ext4 and its faster mkfs. Even cooler would be better scalability in ext4 (This side seems to have seen not enough effort lately).

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

Hans Peter Anvin and Ted Tso are a huge source of deep linux-2.6 knowledge and personal wisdom. I do enjoy all sorts of interactions with them.

Christoph Hellwig with Matthew Wilcox and also William Irwin for setting up the Debian kernel Team.

Several Debian leaders including the previous and the current one for their engagement, which very often happens behind the scene.

The Debian Gnome Team work is great, also the interactions have always been always easy and a pleasure.

Martin Michlmayr and previously Thiemo Seufer do an incredible job in porting Debian on funny and interesting ARM and MIPS boxes. Debian has a lot of upcoming potential on this area. I’m looking forward to other young enthusiastic people in that area.

Colin Watson is bridging Debian and Ubuntu, which is an immense task.

Michael Prokop bases on Debian an excellent recovery boot CD: http://www.grml.org. I’d be happy if any Debian Developer would work as carefully coding and working.

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

Tags

Recent Posts