The Debian New Maintainer Process

Dafydd Harries, Hanna Wallach, and Moray Allan gave an interesting Debconf talk on the Debian New Maintainer (NM) process and thought I would throw in my two cents. If this looks familiar, it’s because I made the second half of this argument on debian-newmaint a long time ago without much effect.

I see two major problems with NM as it stands right now:

  • The idea of "developership" in Debian collapses package maintainership and membership or citizenship into single quality.
  • Quite simply, NM focuses too little and too indirectly on the qualities that make good Debian developers.

At a certain point, the end result of each of these is the same: we create barriers to entry that block good developers. Some believe that the procedure also fails to block bad developers although I’m personally less concerned about that.

Developership and Citizenship

Being a Debian developer means that you have a key in the Debian keyring. This allows all developers to upload packages into Debian but also allows them to vote in General Resolutions and Project Leader elections. There is only one keyring for both of these things. Because all developers can upload packages, the process to become a developer tests packaging skills. While it is possible for non-technical folks (e.g., documentation or translations folks) to become developers, there is a understandable queasiness about adding keys to the keyring for folks who have not and do not intend to upload.

My favorite example was always Greg Pomerantz who is Debian’s lawyer. In terms of time, effort, and impact, Greg contributes to Debian more than most developers. However because he did not maintain packages and was not interested in doing so, he was not enfranchised within the Debian political system. Greg’s example is now less good because he’s started maintaining packages and jumped into the normal NM queue but I think his example highlights a serious shortcoming in the Debian system.

In Ubuntu, we have split "membership" from upload privileges. Members are people who have testimonials from trusted members of the project, who can demonstrate a history of substantial contributions, and who have agreed to our foundation documents. Membership conveys voting rights but — unlike Debian — expires with inactivity. While only members can upload, members cannot upload by default. They must first be checked off by a board of technical guardians who will look at their sponsored package history.

Now, I’m not convinced that Ubuntu’s model is the best way for Debian. However, if Debian really can’t separate uploaders from voters, I think that our NM process should test less on specifics and more for people that know their own limitations. Branden Robinson had an interesting idea I’ll let him propose on his own but I think might be a great retroactive fit for Debian.

Selecting For Quality Maintainers

On the second point, I am increasingly frustrated with the way that tasks and skills are handled in Debian. When I went through NM I was asked (and answered) exactly zero task and skills questions. I made packages, upgraded packages and fixed bugs. My work was vouched for by others and left to speak for itself.

What I ask to my NMs is similar to what was demanded of me. I ask few, if any, questions but look for, and require, active engagement with the Debian and free software communities. If people are doing good work and have great technical reviews from sponsors and are creating clean, well documented packages, and demonstrate that they know when and how to read a manual, this should be enough. I heard a talk from a famous biologist a couple years ago who told a story that went something like this:

A group of scientists bred mice so that they were really good at running through a maze. Many generations down the line the mice that made it through the rigorous breeding selection process were really good at running through the maze; but they were also partially deaf and partially blind. Partially blind and deaf mice are less distractable and are better at running through mazes. The mice were no smarter or better than other mice — just worse in a way that was helpful in the narrow case of the test.

I’m afraid the length and depth of the NM process is, in many cases, selecting for something other than competence, reliability, and knowledge of and adherence to our policy, philosophical, and quality standards. I half-jokingly believe our system is selecting for people who like researching and writing very long series of emails over people who enjoy going out and getting high quality programming work done in a consistent and reliable way.

Imagine the flame wars of the future.

2 thoughts on “The Debian New Maintainer Process”

  1. I’ve been in NM for just over a year, but I’ve only had an AM for about 10 months.

    I started to get really frustrated when I found myself feeling guilty for only having enough Debian time for one of two things: maintainership, or the NM process – and choosing maintainership.

    sigh

  2. I have been in the Debian NM process for a few years now.

    Every once in a while I decide to set aside the several hours it takes to answer all those questions.  I do it and send them off.  Months go by and new questions come back.  “List all the steps required to create a new Debian package.”  “Explain the meaning of all the possible arguments that maintainer scripts can accept.”  “How do you package perl modules?”  On and on.  The questions seem designed to waste as much of my time as possible.  No account is taken of the fact that I am already maintaining several packages in the Debian archives, the contents of which prove that I know the answers to these questions.  When I point this out I am told that the Debian Account Manager won’t have time to look at my packages, so I had better answer the questions or “go away”.

    For this and other reasons of a similar kind I am not really looking forward to becoming a bona fide Debian Developer.  It will make uploading more convenient, but I certainly won’t consider it an achievement, much less an honor.

    In contrast, some time ago I was approached by an Ubuntu developer who wanted to know if I was interested in becoming a maintainer over there.  He said he’d seen my work and would vouch for me.  That’s all it would take!

    Suffice it to say that I am now running Breezy…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>