On Wednesday, November 13, 2002, at 04:20 AM, Rodent of Unusual Size
wrote:
Costin Manolache wrote:
What you would have liked is your problem. As I repeated quite a few
times and you don't seem to hear is that the decision about a release
is a majority vote and can't be vetoed - even if it pisses off some
people.
not strictly true, although mostly. a product release may be effectively
vetoed by the asf officer with oversight of the project, if it appears
in that person's judgement that releasing it would be the Wrong Thing
for the foundation. in that case, it doesn't matter what the majority
think, since the product is an *asf* product and not just theirs, although
they certainly have the privilege of and responsibility to try to convince
the officer (pmc chair) of the Rightness of the view to release.
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
