I was forwarded a pretty interesting (and funny) email thread on Apache MINA‘s mail list. It seems a MINA developer was upset that a particular checkin did not have @See Javadoc comments. So much so, he vetoed the commit.
“I’m on the project *management* committee.
I would like to see the code you commit adheres to some standard.
Until this is resolved my right to veto holds so please revert your commit until we figure out the best choice for Javadoc. If you won’t revert it, I can do it for you.”
A huge flamewar ensued thereafter. This is why I would never, ever host an open source project at Apache. Its not because a silly flamewar happened over a trivial issue. We had a similar one errupt over Steve Ebersole putting in SL4J in Hibernate. Poor Steve had a few of us flaming him. In true JBossian fashion, Steve, the project lead, basically said, “bleep you. I’ve researched the issue thoroughly and I’ll do what I want and think is right.” No, the actual reason I’d never go to Apache is that anybody is allowed to veto your commit via the Apache rules:
“PS : for the record, here is the veto definition (http://www.apache.org/foundation/glossary.html) :
*Veto* According to the Apache methodology, a change which has been made or proposed may be made moot through the exercise of a veto by a committer to the codebase <http://www.apache.org/foundation/glossary.html#Codebase> in question. If the R-T-C <http://www.apache.org/foundation/glossary.html#ReviewThenCommit> commit policy is in effect, a veto prevents the change from being made. In either the R-T-C or C-T-R <http://www.apache.org/foundation/glossary.html#CommitThenReview> environments, a veto applied to a change that has already been made forces it to be reverted. Vetos may not be overridden nor voted down, and only cease to apply when the committer who issued the veto withdraws it. All vetos /must/ be accompanied by a valid technical justification; a veto without such a justification is invalid. Vetos only apply to code changes; they do not apply to procedural issues such as software releases.”
Imagine going to your boss or project lead at work and saying “I veto this commit.” How hilarious would it be to see the look on their face? Seriously though, democracy just doesn’t work in software development. There are too many ways to skin a cat in software. Its hard enough to get code released on budget and on time without some stupid random schmuck vetoing your work.
BTW, if you think this is funny, check out this old PMC complaint. In this case, it wasn’t a developer vetoing a commit, it was some Apache bureaucrat putting down the hammer.