Gianugo Rabellino wrote:
What has been discussed that results in an increased number of, or
complexity of, gates for non-committers?
Er, well, the whole idea that being a committer is not enough
Doesn't seem to really change the non-committer's gate.
that getting code in requires explicit code review and a vote from
peers
Yet your "ideal" workflow cited later includes strong RTC for many
things. The inconsistency doesn't make much sense to me.
2. Apache has a somewhat strong definition of roles. Once you're a
committer (well, actually a PMC member), your vote counts as anyone
else's. Even the PMC chair has one vote which is equal to any other.
While there is some wiggle room, I'm pretty much positive that a
policy considering votes for some PMC members as more important than
others will clash with ASF procedures.
I'm pretty sure we've also been told in the past that the PMC is
pretty much free to define whatever processes it wants, as long
as the bylaws aren't violated.
If a project can have multiple codebases, with independent committer
sets, yet there's a single PMC (it is a PMC, not a CMC, I assume), then
your concern about vote asymmetry doesn't seem to quite mesh.
It does indeed, that's the very notion of trust: if you're getting
commit access, this is because you're deemed to be *both* technically
savvy
Projects and codebases have no consistent size, shape, or complexity,
so savvy-ness for a large project is likely either naiive or
imposing an unacceptable barrier to entry.
and socially capable of interacting with a community and
understanding where you should be committing code and where you'd be
better ask for peer review in advance.
Which isn't a per-codebase attribute.
If you take the social bit out
of the equation, clearly you need demarcation lines between spaces
you're allowed to mess with. But doing so also impairs the whole trust
notion.
So with the social bit in, committer privilege should apply to all codebases,
it seems.
- Bob
