|This article brought to you by LWN subscribers|
Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.
The Debian technical committee has a role similar to that of the US Supreme Court: it makes the final pronouncement on disputes that cannot be resolved otherwise. It also resembles the Supreme Court in another way: an appointment to the committee is essentially "for life"; in the absence of a resignation, there is no natural end to membership on the committee. Recently, there has been discussion aimed at changing that situation, but the form of a better arrangement is not yet clear.
As described in the Debian constitution, the technical committee can have up to eight members. The committee chooses its own members, subject to approval by the Debian project leader. The size of the committee has varied over time, but is usually close to the full eight members.
Anthony Towns started the discussion in May, noting that some of the members of the committee have been there for quite some time. Ian Jackson appointed himself to the committee in 1998 as the brand-new Debian constitution was being adopted. Bdale Garbee came on board in early 2001. Andreas Barth and Steve Langasek have both been members since 2006; Russ Allbery and Don Armstrong were added in 2009. Colin Watson is a relative newcomer, having joined the committee in 2011, and Keith Packard, member since late 2013, is still rather wet behind the ears. Anthony raised no complaints about the performance of any of the committee members, but did note:
There was almost no opposition to the idea of establishing some sort of term limit for technical committee members, even among the committee itself. Russ Allbery suggested that he has been considering voluntarily limiting his own term, regardless of what the project might decide to do. But the discussion on how these limits might be applied was rather less conclusive. It is not that there is disagreement over how it should be done; instead, there seems to be widespread uncertainty about the best approach to the problem.
The reasons why term limits might make sense were perhaps best expressed by Russ:
Russ also pointed out that the "for life" nature of technical committee appointments causes the selection process for committee members to be highly cautious and conservative. Limited terms would lower the level of perceived risk in appointing a developer to the committee, possibly increasing the set of viable candidates.
Those reasons, however, do not necessarily answer the question of what the policy should be. Should, for example, technical committee members be limited to a fixed number of years on the committee? There is an immediate practical problem there: if the limit were to be set to, say, four years, six of the current members would immediately be forced out. The project seems to agree that this would be an unfortunate result; while there is value in bringing new perspectives to the committee, there is also value in maintaining a certain amount of continuity and experience there.
Various ways of fixing the problem were proposed; many of them involved assigning artificial appointment dates for the current members to avoid having them all expire at once. An alternative would be to put a cap on the number of members whose terms could expire within a given year. So, even if six members were over the adopted limit, only the two most senior members would have their terms expire immediately.
There is also the question of when a member whose term has expired can be reappointed to the committee. The technical committee is currently self-selecting; it appoints its own members, subject to approval from the project leader. One could imagine a longstanding committee that is happy to immediately reappoint members when their terms expire, defeating the purpose of the whole exercise. So there probably needs to be a mandatory down time during which previous members cannot return to the committee.
One other question has to do with how this change, if it is made, is to be enacted. The rules for the technical committee are written into the project's constitution, so a constitutional change seems like the obvious way to apply term limits. That, of course, would require a project-wide vote via the general resolution mechanism. Ian, however, suggested that a better approach might be for the committee to adopt its own term-limit rules.
The primary motivation for applying limits at that level has to do with items that are currently under consideration by the committee: it would have been awkward, for example, if a member's term had expired in the middle of the recent init system debate. If the committee enforced its own term limits, it could delay an expiration for long enough to bring a contentious issue to a close. Doing things at that level would also make it easier to experiment with different approaches, Ian said, and would allow an outgoing member to vote on their own replacement.
After thinking on the issue for a while, Anthony posted a pair of proposed resolutions, either of which could be adopted to apply term limits to the technical committee. The first of those reads like this:
Additionally, members could not be reappointed to the committee if they had been a member for more than four of the last five years. Anthony expressed some discomfort with this option, though, noting that Keith would likely become one of the senior members and be pushed out of the committee after just three years. So he also put out this alternative:
In this variant, members could be reappointed after a one-year absence from the committee. This version ensures that all members are able to serve for a full six years and also limits the (forced) turnover to two members per year. It should, thus, satisfy the goal of bringing in new members while preserving a certain amount of continuity.
Anthony's proposal has not been put forward as a general resolution at this point; indeed, responses to it have been scarce in general. Perhaps the project as a whole is slowing down for the (northern hemisphere) summer. Given the apparent overall support for the idea, though, chances are that something will happen once Debian developers return to their keyboards.
Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds