Vancouver goes to Helsinki

August 31, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

The Debian release team meeting held in Vancouver in March spawned a proposal for creating quality requirements for Debian ports to trim the herd of supported architectures. That proposal, not surprisingly, generated quite a bit of heated discussion among Debian developers.

Wouter Verhelst called for a follow-up meeting at Debconf5 in Helsinki, and has submitted a report covering the discussion at the meeting. According to Verhelst's report, several points from the Vancouver proposal were discussed.

The first of the "problematic items" is the requirement that "an architecture must be publicly available to buy new". This was clarified to mean "new hardware which, as of yet, is only available under NDA, or to avoid things such as a Vax port of Debian" and not to be applied retroactively to existing ports. Since it would be difficult, at best, to provide widespread access to hardware that requires Debian developers to sign an NDA, it seems a very reasonable requirement.

The next sticking point is the requirement that "any architecture needs to be able to keep up with unstable by using only two buildd machines". Unfortunately, Verhelst reports that "we didn't reach an agreement; in the end, we decided to move on." There will be more debate, but the requirement will remain in the meantime.

Another topic of discussion in Helsinki was the veto powers that would be given to the Debian System Administrators (DSA), Release Team and Security Team. Those teams would be able to veto an architecture if it would have an adverse impact on the quality of the release and/or the length of the release cycle.

There are still those who object to the "arbitrary" veto powers, but Verhelst responds that if it's abused, the team vetoing the release can be overridden:

That's why we introduced the rule that if one of the teams decides to use their veto power, they /have/ to explain themselves. If someone then posts something like "I've had a fight with <foo> the other night, so I'm going to make him feel sorry for it and drop his port", I suspect requests will go to the DPL to please replace this person. Or if someone posts a rationale to drop a port consisting of arguments each of which are completely and utterly false, that a discussion will follow, pointing this out, and (ultimately, if the team isn't convinced) a GR to overrule the decision.

We also asked Debian Project Leader Branden Robinson for input on Helsinki meeting, and whether the veto power was necessary and how to make it more acceptable. Robinson said he was "equivocal about it".

On the one hand, certain administrative issues do tend to get concentrated in particular roles, and I can empathize with how it can feel unfair to a person in such a role to be expected to do certain kinds of work to ensure a port is sustainable because no one else is bothering. In many situations, to do your nominally-appointed task A, you have to also do tasks B, C, and D, and if the developers in general aren't doing them, even if they should, the "privilege" falls upon you. Because if you don't, the work won't get done and then you *will* be accused of sabotaging or ditching the port.

At the same time, the concerns of the developers in general are legitimate. We *should* be cognizant of concentrations of privilege and power, because then we render ourselves susceptible to decision-making based on personality rather than consensus. Again, Biella Coleman's paper describes how the Debian Project is culturally uncomfortable with such a possibility.

I think the only real long-term solution to these problems is to decentralize our processes as much as we can. This is difficult in part because there is much expert knowledge locked up in the heads of people who either don't have the time or the inclination to serve as mentors or documentation-writers. As Coleman describes in Chapter 6 of her dissertation, there is a strain of the meritocratic geek philosophy which holds that self-education is the only legitimate avenue to exercise of authority. In my view, while it's certainly laudable to encourage people to grapple with challenging and unfamiliar code, material, or concepts on their own, this process demonstrably leads to the entrenchment of elites.

The "98 percent rule," requiring a port to compile 98 percent of the archive's source, is also generating quite a bit of discussion. A look at the build daemon statistics can be instructive in seeing how well each port is doing in terms of building packages. However, there's little point in worrying about those statistics right now while things are still undergoing rapid development, as Steve Langasek points out:

The result is that it will be rather difficult for a while to *measure* how well ports are keeping up, so there's probably just no sense in trying to until things cool down in unstable.

In his report, Verhelst suggests that the Vancouver proposal was not intended to "kill off" some of the Debian architectures. Langasek, who was not at the Helsinki meeting, clarified that the intention of the Vancouver proposal was "motivated by a concern that the absolute count of release architectures in Debian is too high to be sustainable".

We asked Robinson if it was likely that any ports would be dropped from Etch, and he replied that "it's possible that a currently supported architecture will be dropped. I don't yet consider it likely. I think the reason for dropping an architecture for Etch, if it happens, will likely have to do with build daemon failures for that architecture."

It would appear that the Helsinki meeting has moved the ball forward a bit in terms of developing a set of release criteria for Debian ports. However, it's also clear that there will be a great deal more discussion before a final set of criteria is adopted.

Obviously, no matter what the final language, it will not make everyone in the Debian community happy. However, we think that the Vancouver proposal is a good start towards making the Debian release process faster and more predictable.

Index entries for this article
GuestArticles	Brockmeier, Joe

Vancouver goes to Helsinki

Posted Sep 1, 2005 8:04 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

was there any discussion/change on the requirement that any 'first class' architecture needed to be x% of downloads? (I don't remember the percentage listed, but it would have excluded everything except x86)

Vancouver goes to Helsinki

Posted Sep 3, 2005 12:30 UTC (Sat) by aba (guest, #24118) [Link]

The x%-thing is the one about the mirror split - and that was not part of the discussion in Helsinki. (And frankly speaking, even as of now there are lots of mirrors who only carry i386.)

Good news.

Posted Sep 1, 2005 22:10 UTC (Thu) by ncm (guest, #165) [Link]

To me this means progress toward being able to say, at some point, "we could release now without architecture Z, or at some unknown time in the future with Z; therefore we're dropping Z and releasing now." Presumably Z could be added at any time later, when it's ready. No architecture, then, need be officially dropped, although its build servers might be reclaimed after it misses too many releases.