river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gianugo Rabellino" <gian...@apache.org>
Subject Re: development process
Date Thu, 30 Aug 2007 07:38:45 GMT
On 8/30/07, Bob Scheifler <Bob.Scheifler@sun.com> wrote:
> 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?

Er, well, the whole idea that being a committer is not enough, and
that getting code in requires explicit code review and a vote from
peers (not to mention the idea of having people whose +1 is more
important than other's - the "gatekeepers" you've been mentioning)...
all that speaks of barriers to me. Am I the only one?

> > 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.)

What I meant is:

1. I consider having different kinds of committers dangerous in itself;

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.

> ASF already has something stricter than gatekeeper: committers are
> committers only for a specific codebase, not all of ASF-land.

Yes, and that's pretty much the only line in the sand. Once you're a
committer, you're granted access to a specific codebase, and all of
it.

> 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. ;-) )

Heh, specs are buggy as everything else. :) Anyway, this is feasible
but requires an explicit split, something I wouldn't say we're quite
ready for. And, again, it might be detrimental in terms of drawing
community boundaries.

> > 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?

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 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. 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.

Ciao,

-- 
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)

Mime
View raw message