Debian and Ubuntu have a set of official membership roles that can be granted to regular contributors. Those roles come with rights that enable the contributors to do their work and to participate in the project governance (elections and other official decision-making processes). It s also a way for the distributions to acknowledge the work done: most contributors are proud of the status they reached.
The membership structure plays an important role in the development of a distribution: it defines the kind of contributors that are welcome in the project, it sets expectations of the project towards its contributors and defines their rights. In the end, this shapes the project s ability to recruit new contributors to keep the project alive and kicking. This article introduces the existing statuses in Debian and Ubuntu, and defines the sometimes confusing jargon associated with them.
The Debian Case
Debian only has two types of official members:
Debian Developers (DD) and
Debian Maintainers (DM). The rights of the developers are codified in the
Debian Constitution while those of the maintainers have been defined in a
general resolution of 2007. The Debian Maintainer status is still mostly documented in
a wiki page. The integration of this new status in Debian s official processes has been slow to come largely because it was introduced at that time without enough negotiation with the involved parties. Nowadays, it is preferred that people get the DM status before applying for DD.
DM is a very limited role: maintainers can only upload packages that already have their name on them (either in the Maintainer or Uploaders field) and a specific flag (DM-Upload-Allowed: yes) that only Debian Developers can add. They have no other rights and limited access to Debian s resources.
Besides those official roles, there are also maintainers of packages that have no official status within Debian except that they are listed in the Maintainer field of the package. They are doing the maintenance work but all uploads are done by a Debian Developer after verification of the work done (this is called sponsorship and is the only way to start with official packaging work). Once the DD trusts the maintainer, the developer will typically ask the maintainer to apply for DM status in order to be relieved from the sponsorship work.
In the end, that makes three different kind of package maintainers and a lot of confusion when you discuss membership issues in particular when the
New Maintainer process is the path that you follow to become a Debian Developer. Don t be fooled by the names when reading Debian s documentation!
The Ubuntu Case
Ubuntu had, from the start, an official
Ubuntu Member status that includes all contributors: developers of course, but also documentation writers, artists, translators, etc. This status notably grants the right to vote in elections of the Community
Council, the right to participate on
Planet Ubuntu, and the @ubuntu.com email alias.
For
developers, the situation is more complicated: the wiki page lists no less than five different statuses. Initially, developers were split between
Ubuntu Core Developers and the
MOTU (Masters Of The Universe). The latter were responsible of the universe/multiverse sections of the archive while the former also had upload rights for the main/restricted sections. But, inspired by the Debian Maintainers concept and facing concrete problems in terms of archive management, they changed their infrastructure to offer more fine-grained control on package uploads.
Ubuntu can now grant upload permissions on a package-per-package basis, but it can also delegate the right to grant upload permissions with the same granularity. This lead to the new
Per-Package Uploader status which is simply an Ubuntu Member with upload rights on a limited set of packages where they have a specific expertise. The more generic
Ubuntu Developers status now encompasses members of various development teams that have been delegated the right to manage upload permissions on a (usually large) package set (the current teams are Ubuntu Desktop, Mythubuntu, Kubuntu, and Edubuntu). Those teams can define their own policy to add new members provided they follow the basic rules defined by the Developer Membership Board (see this
wiki page).
Ubuntu Contributing Developer is an intermediate status for someone who is not yet ready for one of the other developer statuses but who has still shown enough commitment to be an Ubuntu Member.
All those statuses can be
obtained in a similar way: you prepare a wiki page listing your past contributions, you collect testimonials from existing members that you have worked with, you add yourself in the agenda of the next meeting of the board (or council) that grants the status that you seek, and you attend the meeting. The members of the board will decide whether you are ready for the status (or not) based on what you provided in the wiki, based on your answers during the meeting (and on a mailing-list for developers), and based on what others have to say about you.
The most important boards are usually
elected by the community while others are commonly appointed by the community council. Those governance bodies include Canonical employees but not as many as one would expect: two out of eight in the
Developer Membership Board, two out of eight in the
Community Council, but all six members of the
Technical Board. The last figure, while not intended, is not surprising given the high expectations set on potential members of the technical board. Mark, as the founder, is the only person to have a permanent seat on both the Community Council and the Technical Board.
Comparison of the Statuses Between Debian and Ubuntu
The following table summarizes the rights given to each developer role in the two projects (Put the mouse over the abbreviations to know what they are referring to).
| Rights |
Debian |
Ubuntu |
| DM |
DD |
UM |
PPU/UD |
MOTU |
UCD |
| Package maintenance via sponsorship | Y | N/A | Y | Y | Y | N/A |
| Official email alias | - | Y | Y | Y | Y | Y |
| Participate in votes for members | - | Y | Y | Y | Y | Y |
| Participate in votes for developers | - | Y | - | Y | Y | Y |
| Upload rights restricted to pre-approved packages | Y | - | - | Y | - | - |
| Upload rights restricted to a section of the archive | - | - | - | - | Y | - |
| Unlimited upload rights | - | Y | - | - | - | Y |
| Number of contributors (as of 2010-07-27) | 117 | 904 | 462 | 27 | 85 | 63 |
Please note that the number of contributors are not 100% accurate for Ubuntu. A contributor can have multiple statuses (direct membership to a launchpad group) granted over time (while gaining experience). The problem has been mostly avoided by calculating differences between number of members of the various groups but it s not perfect and it can t be: some MOTU are also PPU for packages in main and it s legitimate (but I only counted them as MOTU and not as PPU). Another limitation is that members of some administrative teams are included indirectly in many teams and thus appear in the count while they should not.
Anyway, this simple table makes it obvious that Ubuntu s structure offers a broader choice of statuses. They acknowledge the work of all contributors from the start while still giving the most critical rights only to those who have proven that they deserve them. Despite this difference, Debian still has a significant advantage in terms of number of developers. That number does not tell the whole story though: the Ubuntu contributors include many Canonical employees (e.g. 36 out of 63 core developers have a @canonical.com email registered on their launchpad account) that are likely to spend more time working on the distribution than the average Debian member. But even if comparing person-hours would be a challenging thought experiment, in practice it s of not much interest if both projects continue to cooperate and if more and more of the contributions flow in both directions.
Debian is aware of the shortcomings of its structure. Changes to better accommodate non-packagers have been discussed several times already. The
last efforts in that direction were unfortunately perceived as a solution ready to go rather than a proposal to be discussed, and the project got quickly buried by a
general resolution (GR). Even if that resolution invited for further discussion and a new proposal, the truth is that when someone s initiative is corrected by way of GR, it usually kills any motivation to go forward.
Possible Evolution?
On the Ubuntu side, the infrastructural changes were completed recently and they don t expect any further change in the near future. They do plan, however, to expand usage of those new features so that more teams benefit from the possibility to control upload rights on packages that are relevant to them, and so that more individuals developers apply to become Per-Package Uploaders on packages that they know very well.
On the Debian side, a recent discussion on the debian-project list brought back the topic of the
bad terminology and it was agreed that the New Maintainer process should be renamed into something else ( New Developer process has been suggested). But Christoph Berg Debian Account Manager and hence heavily involved in the New Maintainer Team
suggested that Debian would be better off implementing the long-awaited membership changes before trying to update all the documentation. It would certainly imply some more vocabulary updates. Later in the discussion, he confirmed that membership reform is on the top of the TODO list of the new maintainer team (just after the rewrite of the
nm.debian.org website).
What can be expected from this reform? The following answers are my own guesses based on my experience of Debian, but the project hasn t decided anything yet.
- First of all: a new status for contributors that are not packagers. The tricky part will be defining the process to follow and the rights granted.
- Changes to the technical implementation of the DM status. The current implementation does not allow to give upload rights to a single DM if two are listed in the Uploaders field of a package (and both might not have the same experience for that package). Furthermore, it suffers from annoying restrictions like the inability to upload new binary packages.
- A change of the Debian constitution to integrate those new statuses is almost unavoidable.
- Other more invasive changes have been proposed like replacing the NM process by a simple designation by other DD, but it s unlikely to happen. The NM process can already be greatly simplified by the application manager if the applicant can show good testimonials from other developers and if he has a track record of real contributions (e.g. as witnessed by changelog entries in Debian packages).
Almost two years have elapsed since the previous efforts in that direction, the new maintainer team has recruited new members and is in a general better shape. Hopefully, the next episode of this saga will have a better outcome.
This article was first published in Linux Weekly News. In a comment, Mark Shuttleworth tried to explain how the Ubuntu community is being setup.
10 comments Support my work
I'm swinging on the front porch shade, with happy wifi bars lit up on my
laptop. A good network makes for a happy home, isn't that how the saying goes?
(Maybe not yet.)
Typically that's easy to achieve -- here it wasn't. The house is solar powered,
the only connection to the outside is a phone line. So I needed a computer
that would work in that environment, using minimal (12 volt) power, and
getting the most out of the limited bandwidth while providing those
happy wifi bars.
At DebConf we learned that the name for these little home servers we have been
building for years is "FreeDomBox". All
right then, here's my latest FreedomBox build.
Really, I should have known better than to buy myself a rather 'bleeding-edge' laptop. I suppose I've been lucky with my last couple of laptops and was thinking that pretty much everything works on Linux. Or maybe I'm being picky, because in fact pretty much everything does work on my new Dell Studio.
I bought this laptop mainly because it has a 1920x1080 screen, without being a 17" monster. I had such a monster about four laptops ago (an enormous Sony Vaio weighing in at around 5kg and with a 1hr battery life) and it was an disaster: lots of weird proprietary stuff that never worked, like the external speakers in the docking station. But I loved that screen right up until the day Fraser threw a pair of scissors into it.
With the advent of mass-market 1920x1080 screens I've been waiting for them to arrive in laptops at a reasonable price, and the availability of this screen in a few possible laptops seemed to me to be that point.
It's a Dell Studio 15, and as well as the nice screen, it comes with a new Intel i7 Quad Core CPU, 6G RAM, 640G hard drive and a Blu-ray drive. While there are a few similar models around this one seemed to have the best mix of features-for-weight-and-price, so I bought my first Dell.
I built a USB key with the latest Debian Installer from Squeeze and installed that and everything came up pretty well. I had to use the broadcom-sta driver for the wireless, since the BCM 43224 is not (yet) supported by the free b43 driver (though from looking the mailing list people seem to be working on it, and it looks like it might not be too far away).
Everything seemed good. X came up on the (georgeous) screen. I don't care too much about 3D performance, but it was nice to note that the ATI 5000 series is expected to have full support as soon as it's integrated into the right places - it seems the code is written, and public, it just isn't incorporated into the 'radeon' driver quite yet. The fact that ATI is nowadays a free-software friendly company was one of the reasons for choosing this, in preference to an NVidia-based laptop.
But it seems that it isn't all roses. The fan in the laptop seems permanently on, and not on, in a quiet-just-barely-audible way, but ON, in an 'IN UR LAPTOPZ KOOLIN UR P0RCESSAZ' kind of a way. Too damn noisy for me to concentrate in a quiet room.
I've investigated what's going on, and it seems likely there are some ACPI misunderstandings happening. Some googling and some pecking around in /sys makes me wonder if the laptop expects some kind of configuration choice between favouring Active cooling and Passive cooling, and it's defaulted to the first one. Perhaps you get better benchmarks that way.
Linux ACPI also seems to only half understand it, it has two thermal zones, and one of them always appears with 0 temperature. I can see set points for the fans, but have no control over them. In particular this got me out reading the ACPI 4.0 specification, and it explicitly mentions this choice of favouring 'Active' vs 'Passive' as being done by configuring the passive trip point setting to a higher value than the low & high active trip points.
In the ACPI 4 spec (page 409) it says:
By default the status is in the mode line only if you are in the Gnus group
buffer. But that's customizable, of course, since this is Emacs!
If you are using 
Russel Garlick writes on behalf of the KohaCon10 Organising Committee:
Some careful readers of 
Without further ado, here are my recommendations for september:
Two weeks ago, Maria and I completed
We managed to complete this challenge without facing major problems or
pains, and after the first five our six days, our legs seemed to have
gotten used to the daily effort and it started to be easier and easier.
Our morale kept growing as days passed and we advanced east. When I
started walking on a cold and rainy morning in Hondarribia, after barely
no rest in the night bus to Ir n, I thought for myself that it was
improbable that we'd manage to get anywhere near Catalunya, that one of
us would get injuried way before, or we'd just give up and go for the easy
beach vacation in the Basque Country.
This adventure through GR 11 has been incredibly positive for us for
several reasons. We've learned a lot about ourselves and strengthened our
relation, and now I know how powerful drive can be; to get somewhere, no
matter how far, it's really easy if you just believe you can do it and
desire to get there.
Maria and I are proud of what we've done, and no wonder we're looking
for new challenges. An obvious one would be repeating this experience,
going through the French side of the Pyrenees, but for now, the Corsican
GR 20 seems the most appealing. We'll see, next summer!
The last few weeks I have been using LaTex a lot, to write the final report
for my master's course. During that period I found a couple of LaTeX goodies
that might be interesting to share: the memoir class, gnuplot integration, and
some stuff to help preparing cover pages.
The 
For me, the most enjoyable part of traveling is the inspiration that I derive from visiting different places, talking to people, and generally being outside of my normal environment. This bank holiday weekend, when so many Londoners visit faraway lands, my partner and I stayed in London instead, and my sought inspiration closer to home. The city has been delightfully quiet, and in contrast to the preceding week, the weather was mostly pleasant, apart from the sudden downpours the BBC described as squally showers .
A number of things have happened in and around forked-daapd in the last month or so, so let s review the new features and the plan for Squeeze.
On the features front, Kai Elwert has done a lot of work since July to implement missing features at the DAAP and DACP level to get better support for Remote:
As a lot of people are coming to my blog to read the 
If you find that running Windows makes a GRUB 2-based system unbootable (