Debian's election season: old firmware and new contributors

Longtime LWN readers will be aware of your editor's tendency toward the publishing of wild predictions at the beginning of each year. The 2007 predictions irritated some Debian developers and users by suggesting that, after getting the Etch release out the door, the project would go back to arguing about firmware issues. At the end of the year, it became necessary to acknowledge that this prediction, like so many others, had failed to come to pass. In retrospect, the error in this prediction was obvious: the Debian Project traditionally saves the firmware argument for the end of the release process. After all, they need to find some way to delay a release once it's looking close to ready.

The problem with firmware, of course, is that it is a binary blob lacking the corresponding source, and, sometimes, even a license allowing its distribution. Many developers and users see that blob as being part of the hardware; as long as the blob is distributable, it does not bother them. Others, though, regard firmware blobs as proprietary software and their incorporation into the kernel as a GPL violation. The Debian Project, which promises to deliver a 100% free distribution to its users, houses many developers from the latter camp. These developers, who see firmware distribution as a violation of the project's social contract, can be counted upon to raise the issue each release cycle.

In 2004, the project responded by passing a general resolution suspending some social contract provisions through September 1 of that year on the reasoning that it would be long enough to get the Sarge release done. Putting a date on a Debian release tends to be a mistake, though; Sarge was not finished until June, 2005. By unspoken consensus, that date was somehow deemed to have fallen before September 1, 2004. In 2006, the project voted again on firmware. Having learned from experience, the exception they allowed this time lacked a date, simply saying that the presence of binary-only firmware in the Etch release was something the project was willing to tolerate.

The 2008 discussion started when Ben Finney pointed out that a number of firmware-related entries in the Debian bug tracking system had been quietly marked "lenny-ignore" - not relevant to the upcoming Lenny release. This action, many have subsequently argued, runs counter to the social contract and constitution, which do not allow the shipping of non-free software to be swept under the carpet in this way. They would, instead, like to see the kernel team remove the (relatively few) firmware blobs remaining in the kernel. Such a change, it is said, should be relatively easy; recent changes within the kernel are helpful in this regard - though said changes became available in 2.6.27, which is not the kernel expected to be shipped with the Lenny release. For the 2.6.26 kernel used by Lenny, Ben Hutchings reports that he has done the necessary work to excise the remaining firmware.

On the other side, there are developers who are more concerned about (1) getting the Lenny release out as quickly as possible, and (2) making sure that hardware Just Works for Lenny users. They would rather that the process of removing firmware continue independently of (and without delaying) the Lenny release.

This is Debian that we're talking about, so the issue will probably be decided by way of a general resolution. There are currently two sets of resolutions being circulated, though neither has reached a final state for voting. The first set addresses the Lenny question, providing two options: either delay Lenny until the firmware removal work is complete, or accept that - just once more, really this time, honest - a major Debian release will include some firmware in its kernel. (The "ship Lenny" option is actually two options, one allowing firmware and one allowing Debian Free Software Guidelines violations in general). What the project will decide once this resolution comes to a vote is unclear - but Debian's developers have always voted to get the release out in the past.

The second proposal addresses what happens after the Lenny release; it says that any package which violates the Debian Free Software Guidelines for more than 180 days will be forced into the non-free repository. The clear hope here is to ensure that this tiresome discussion doesn't happen yet again in the next release cycle. By the time the next release is getting close to ready, any non-compliant packages will have long since been banished to the non-free wasteland. If it ever comes down to moving the kernel to non-free, though, one can assume that the discussion will resume with a vengeance.

Developers, Members, Maintainers, and Contributors

Meanwhile, a different disagreement is headed toward - you guessed it - a general resolution. Long-time Debian watchers have noted that another recurring topic of debate is the acceptance of new developers. The new maintainer process involves long delays, tests of ideological purity, and more. Even when it works smoothly (which seems to generally be the case in recent years) it requires a certain amount of patience and determination on the part of an aspiring Debian Developer.

The difficulty of the process is a design feature; Debian developers occupy a position of some trust, and the project wants to make sure that applicants are serious. Over time, though, it has become clear that this process is costing the project the time and energy of talented contributors who do not wish to jump through all the hoops. In response, the project created a "Debian maintainer" designation which allows the uploading of packages, but withholds many of the other privileges enjoyed by full developers. This change appears to have been successful in enabling a larger group of developers to contribute to Debian.

More recently, Joerg Jaspert has proposed lowering the bar to certain types of contribution even further. The proposal reads:

To that end, Joerg would create a new "Debian Contributor" classification. Contributors would be those doing translations or documentation; the proposal doesn't say that contributors don't touch code, but one gets that sense. Contributors would still have to jump through some hoops, but they would be fewer. They would not be able to upload packages on their own. The proposal also changes the Debian Maintainer standards, making that designation a little bit harder to get. Finally, the proposal states that all new applicants to the project would become Contributors or Maintainers. Only after a six-month period would they be able to apply for full Debian Developer or Debian Member status -- "Debian Member" being another new category that, while being equivalent to Debian Developer in almost all respects, would not have package upload privileges.

Interestingly, there has not been much discussion of the substance of this proposal. But there has been a fair amount of debate over how it is being done. It would appear that some developers see this change as being imposed by a single project official without the debate that Debian changes normally require. Martin Krafft has further asserted that this kind of change goes beyond Joerg's authority as Debian account manager, a claim that Joerg denies.

So now there are proposed general resolutions being circulated. An early version simply decreed that the proposed changes were "suspended" in favor of changes to be made through a more consensus-oriented process. Later versions soften the language somewhat, and thank Joerg for his effort in this area - but still require a "consensus or general resolution" before changes are adopted. In any form, the clear point of the resolution is to slow down the process and open it up for a wider discussion.

Again, voting has not begun on any specific resolution, so we don't yet know what will even be voted on, much less how it will come out. But we can expect that, as a certain presidential election process finally (thankfully) comes to a close, activity will be picking up on a different set of votes.

---

(Log in to post comments)