On Sep 9, 2011, at 2:41 PM, Eli Collins wrote:

I think someone got carried away in their artistic flair.  I wrote the
original httpd guidelines.

Volunteers are always needed.  That doesn't mean they are the only
volunteers, nor does it mean they have special veto powers.

Any committer can commit wherever they have been given permission
to commit by the PMC.  Generally, they do so collaboratively.
I've never encountered a situation in my own projects which developers
were committing at cross-purposes, even when they disagree on content,
though I've seen commit wars elsewhere.  We'd expect the PMC
to step in if they did.

The only thing the RM has authority over is the building of a source
package, based on the contents of our subversion, that can then be
put up for vote.  They can decide what snapshot to tag for a build.
They can decide not to build anything at all.  They can also do all sorts
of organizational support, advocacy, pleading, or whatever in order to
encourage the rest of the project committers to apply changes, vote
for things under issue, etc.

They do not have the right to pick and select whatever variation
of the product they might like to build, short of vetoing (with a
valid reason) any changes that they as a PMC member believe do not
belong on the branch. Likewise, the RM cannot include in the build
any change that has been vetoed by others, and their build cannot
be released if it contains any such changes that have been vetoed
since it was built.  The RM has the right to kill their own build
if they learn something during the release process that they think,
for whatever reason, causes the build to be unreleasable.  But the
RM can't stop anyone else on the PMC from taking the same build
and calling for its release under their own management as RM.

The ASF supports collaborative development of open source through
the work of individual volunteers.  If the rules are consistent with
that mission and are applied consistently, then the board is unlikely
to intervene.

As a board member, what I look for is the effect that those rules
have on collaboration.  If I see a bunch of happy developers
collaborating on releases, it really doesn't matter what the rules
are since the rules exist to prevent technical disagreements from
escalating into social conflicts.  If, however, I see no significant
releases, work being done elsewhere, or the project split into
multiple branches that happen to match corporate fiefdoms, then
it is my responsibility to do something to get it back to being
a collaboration.  Sometimes that means we change the rules.