Gianugo Rabellino wrote:
I still contend that the
main objective of this timeframe should be getting others involved.
And it would be damn hard achieving that if there are too many gates
to cross.
What has been discussed that results in an increased number of, or
complexity of, gates for non-committers?
For one, I see the notion of "supercommitter" (or gatekeeper, in Bob
words) as extremely harmful. In ASF-land there is no such thing (and
this is a problem in itself).
(I don't understand the second parenthetical; it parses like a contradiction.)
ASF already has something stricter than gatekeeper: committers are
committers only for a specific codebase, not all of ASF-land.
To cite from
http://apache.org/foundation/glossary.html#Codebase
"Some projects involve only a single codebase, while others have several."
My notion of gatekeeper is akin to dividing up the River project into
multiple codebases with independent committers, but less rigid than that,
as it only imposes a quorum on reviewers.
(No doubt someone will tell me that this part of the ASF web site
also does not reflect reality. ;-) )
And this is why I
see a lot of slippery slopes in introducing control-based processes
that don't take reciprocal trust into account.
Committer privilege being only for a specific ASF project/codebase,
rather than all of ASF-land, does take reciprocal trust into account?
- Bob
