On Wednesday, November 13, 2002, at 04:20 AM, Rodent of Unusual Size wrote:

Umm, you are both wrong. Technical decisions are made by the PMC, according to the PMC bylaws (usually the developer guidelines). Those bylaws do not allow the chair to make decisions by fiat, nor is it safe (legally) for them to do so. The PMC chair is ultimately responsible for oversight, which means being aware of and making sure that the decisions are being made according to our policies, which are mercifully short aside from the redirect to 501(c)(3) obligations. The PMC chairs are further responsible for reporting anything questionable (or simply interesting) to the board.

The board of directors can make decisions about anything, though we have an explicit agreement with members that technical decisions are delegated to the PMCs (read, acknowledged voting committers, because that's what I meant it to say), which means we make "technical decisions" by closing whole projects until the issue is fixed. The Chairman of the Board is responsible for oversight of the board's decision-making process, which includes making sure that the board acts when it must, such as when a project is doing something without legal right to do so. Please note that the board members have taken on legal responsibility for acting on behalf of the ASF when an issue like that occurs, and the only ways to get out of that bind is to force a correction or resign.

Regarding vetoes, in the httpd guidelines (which should still be the same as those for Jakarta), no software can be released without resolving the veto, which happens when the vetoed change is reversed, or the technical reason is no longer applicable (perhaps due to a fork agreed to by the vetoer), or the vetoer simply changes his/her mind and removes the veto, or the person has their voting privileges revoked. There is no way for the majority to "vote around" a veto aside from revoking the vetoer's right to vote at all, which is pretty much an explicit way of telling them to go fork off.

None of this came up with Tomcat once it was acknowledged that 3.x would be implementing a different servlet spec from 4.x, at which point all of the technical reasons for vetoing further 3.x work disappeared. It then simply became an issue of whether or not enough people would work on it to pass the minimal quorum requirement (3 +1s). Under no circumstance did they ever "vote around" a veto.

....Roy