LWN.net Weekly Edition for March 19, 2015

Debian adds technical committee members and considers their role

Debian's technical committee (TC) has been the subject of considerable discussion—even turmoil—over the course of the past year. 2014 saw high-profile debates within the TC, several resignations of long-serving TC members, and a General Resolution to introduce term limits for the first time. So it may come as welcome news that the TC recently added three new members to its ranks with little to no overt drama—although, in the process, thought-provoking questions were raised about how the TC itself would like to see its role evolve in the coming years.

In January 2015, the term-limit resolution was approved, but its effects will not take effect until 2016. In the meantime, TC business has more or less returned to normal. On March 5, the existing TC recommended the addition of three new members: Sam Hartman, Tollef Fog Heen, and Didier Raboud.

These recommendations were given to Debian Project Leader (DPL) Lucas Nussbaum. The DPL is not obligated to act on them, but only the DPL can formally appoint new TC members. Nussbaum indeed did make all three appointments, on March 8. Since the recently adopted term-limit rules take the order of appointments into account, Nussbaum made the appointments in a specific order (first Raboud, then Fog Heen, then Hartman).

Nussbaum explained that his use of this order—which is the reverse of the order of the recommendations—was done so that "the most preferred appointee could serve one more year due to the expiration algorithm" (the "most preferred" in this case being the name put forward first by the existing TC). That outcome would happen because the new term-limit rules only cause two seats to expire in any normal year ("normal," in this case, meaning a year without numerous early resignations). In other words, by appointing Hartman third, Nussbaum ensured that Hartman will have his term expire later than Raboud and Fog Heen.

The turnover process, then, would appear to be working smoothly. Before Nussbaum made his appointments, though, Hartman added one wrinkle to the story by suggesting to the TC that he might be not a good fit for the job, on the grounds that he has some specific thoughts on how the TC should operate that others may not agree with.

Hartman posed his suitability question in a March 4 message to the Debian TC mailing list, saying that he hoped the TC could play a role that helped project members do their technical work "with less project-wide pain." Specifically, he said:

In essence, Hartman wants to see the TC shift its role from that of final authority in otherwise-intractable disputes to one that can offer guidance and assistance on a regular basis—hopefully reducing the number of disagreements that reach "intractable dispute" status. As he explained later in the email:

For example, he continued, the TC might get involved to address communications issues, even if they do not impact the technical quality of the project.

Hartman's first example was vague enough to be open to interpretation, but it seemed to suggest at least the possibility that the TC might resolve some disagreement on the basis of which camp contributes more to the Debian project's functioning as a smooth, happy community, rather than solely on the technical merits of each camp's software:

Continuing, he provided a more specific example, pointing to the early-2014 dispute over whether applications should stick to Debian's traditional menu-file format or adopt the newer format used by GNOME, KDE, and other desktop environments. In that case, Hartman said, the TC seemed to make its decision on the basis of technical correctness, even though that decision sided with a minority viewpoint and upset a majority of the developers involved (who had already gone in a different direction with rough consensus). Ignoring consensus in such cases has the effect of devaluing the effort that people put into their work.

Then again, Hartman also made it clear that he would prefer to see fewer formal resolutions emanate from the TC in the first place. He noted that in the init-system debate, Don Armstrong had contended that every TC decision ought to result in a resolution. Hartman disagreed:

Hartman concluded by acknowledging that Armstrong's position (requiring a resolution from the TC on all disputes) was consistent with the constitution, but suggested that a more liberal reading in which the TC had flexibility to get involved without issuing resolutions, might better serve the project.

Hartman posed the question to the TC in order to ask if his thoughts about the TC's role in Debian were peculiar enough that he should turn down an appointment. Surprisingly, perhaps, no one took issue with his sentiments. Bdale Garbee and Keith Packard both expressed broad support. Armstrong, for his part, suggested that he believes the TC can act informally as well as formally, and that there are a number of ways in which a dispute can be resolved without a formal TC resolution. He also expressed support for Hartman's nomination.

Fog Heen added that "consensus" can have more than one meaning, from complete agreement to "is anybody unable to live with this?" It is important to establish what meaning the TC has in mind, he said, but, regardless of what the answer is, he looked forward to seeing Hartman on the TC.

Ultimately, then, all participants in the discussion felt that Hartman's thoughts about the TC were compatible with their own. Nussbaum made the appointments, after which the new TC proceeded to take up its first official task. Garbee, the current TC chairman, announced that he would be stepping down from the role (since his term will expire at the end of 2015), and called for a vote to select a new chairman. By transitioning to a new chairman now, Garbee's departure next year will have less of an impact on TC continuity. Armstrong won the vote, and the TC moved on to new business.

Nevertheless, the incident may have repercussions for quite some time. The preceding year was a rough one for Debian and the TC in particular; Hartman's questions about the role of the TC going forward may have crystallized similar thoughts that had been just beneath the surface for many TC members and Debian developers. It is unlikely that Debian has seen its last argument, but the project may have learned a few things from its recent encounters with conflict.

Comments (5 posted)

Conflict over a code

It should be emphasized that these are your editor's thoughts; they are not representative of anybody else. The Linux Foundation's Technical Advisory Board (TAB), which is named as the resolving body in the code, and of which your editor is a member, does not even know the article is being written. Even your editor's dog has requested an explicit disclaimer stating that these are not her opinions. But, then, the dog's opinions are mostly concerned with whether something is edible or not.

Perhaps the most surprising thing from your editor's point of view is the articles portraying the code as directly aimed at Linus Torvalds; expressions like "slap down" or "rein in" are not hard to come by. One particularly amusing piece saw it as a deliberate attempt to undercut an "over the hill" Linus and, presumably, take his place. In fact, Linus was given the opportunity to comment on the code and was, of course, the person who merged it into the mainline. It would be unusual for somebody to cooperate in his own reining-in in this way.

If the behavioral problems on the kernel mailing lists could be solved by muzzling one person, the issue as a whole would be much more easily dealt with. But that is not the case here; opinions differ on how large the problem in the kernel community really is, but it is a rare participant indeed who thinks it comes down to a single individual. Attempts to change the way a community behaves generally require addressing the community as a whole; that is what the code of conflict is attempting to do.

There is another line of thought that sees the "code of conflict" as a no-op statement with no teeth. What your editor has heard from a number of sources is that the code looks like an attempt to paper over the problem without actually doing anything about it.

This code does differ from the codes of conduct adopted by a number of other projects. It states from the outset that conflict over technical issues is a part of how the kernel community works. It lacks a list of specifically prohibited behaviors — something that a number of critics have pointed out. There is no list of specific sanctions that can be applied to developers who are deemed to violate the rules, whatever they turn out to be. The code places the onus on the target of abusive behavior to raise the issue with a distant group of ten developers who may or may not have this person's trust. All of this, to some, means that the code is not designed to actually bring about any real-world change.

From your editor's understanding, the list of unwanted behaviors was left out for a couple of reasons: to keep the code short and comprehensible, and to avoid attempts to play games around the edge of the rules. So the actual rule is short and simple: participants are not to be made to feel "personally abused, threatened, or otherwise uncomfortable". The assumption is that targets of abuse can tell whether they feel abused without having to check a list of specific behaviors. The concern that such people may be more reluctant to complain without a specific rule to point to may have more merit. The good news is that the community is full of sharp-eyed observers who are likely to blow the whistle on poor behavior even if the target feels too intimidated to do so.

With regard to specific sanctions, there are limits on what can be done. Those who abuse the kernel mailing lists can already be banned; that has recently happened, for example, to some of the persistent systemd trolls who tried (unsuccessfully) to stir up flame wars recently. There is no community process that could, say, remove an abusive subsystem maintainer from that role. One could imagine that the TAB might advise such a course in an extreme case, but it would be up to Linus to actually carry it out. Hopefully, though, the bulk of any problems raised under the code of conflict can be resolved without resorting to punishments or the threat thereof.

At a different extreme, there are those who see the code as the beginning of the end for the kernel community. In this view, the code will curtail debate over code submissions and lead to a lowering of quality standards overall. In talking to many people about this code, your editor has noted that even those who feel most strongly that it should be more explicit and have sharper teeth do not say that it should become easier to get code merged into the kernel. It seems relatively safe to predict that anybody who complains that their code was rejected on technical grounds will be advised to address the issues raised and try again. There is no reason to believe that the standards for kernel code will be lowered.

Years of writing for LWN have given your editor a (possibly twisted) standard for success: if people on all sides of an issue appear to be equally unhappy with an article, it was probably reasonably fair. By that metric, the code of conflict may well be deemed to have gotten things about right: the complaints from the "it's business as usual" and the "it's the end of the kernel" camps both seem loud. At this early stage, it would have been hard to do better than that.

That said, those who see this code as an exercise in being seen to be Doing Something are probably not entirely off the mark. Doing Something does not always turn into "having done something useful" over time. The real value of this code can only be seen going forward. If it empowers the targets of abusive behavior to speak out, and if it helps to bring a resolution of such situations and end that behavior, it will be a success. If so, the kernel community should become a kinder, gentler place, though, in truth, that has already been happening for some time.

A few years from now, we might just look back on the kernel's code of conflict as an inadequate, failed response. But it is far too soon to predict that with any degree of certainty. The thing to do for now is to give it a chance and see if problems arise that the code's process fails to address adequately. As Linus said when he merged it: "Let's see how this works". Even your editor's dog would agree, especially if it came with something to eat.

Comments (43 posted)