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 Wed, 29 Aug 2007 21:59:28 GMT
On 8/29/07, Bob Scheifler <Bob.Scheifler@sun.com> wrote:

> I dislike code review deadlines; code isn't correct just because a deadline
> passes.  I also don't ever expect committers to be expert in the entire
> codebase, so I'm wary of accepting +1's from only those who don't really
> understand the code being changed.  So for implementation changes I'm tempted
> towards having a set of gatekeepers for each component (achieved by merit),
> and review must have a +1 from a gatekeeper, and no vetoes within
> max(N days, vote by gatekeeper).

I think this email, other than convincing me even more that RTC is bad
in general and wrong in this context, is a clear sign that we need to
step back a minute and try to understand what we are really after.

First of all, what are we trying to achieve? What is our top priority?
As an ASF incubating project, the ultimate goal should be proving how
River is sustainable from a community perspective, much rather than
demonstrating technical excellence. While I can understand that River
is currently used in production in a number of places, with lots of
users relying on its quality and robustness, 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. If the codebase is too complex, the solution isn't raising
artificial barriers to avoid others from making silly mistakes. The
solution making it easier to grasp and provide a good community
framework that clearly outlines roles and responsibilities *while*
promoting participation.

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). We do have people responsiblle for parts
of the code, but this is usually governed by trust and common sense:
people won't  commit crap to the repo just because they can, they will
resort to whomever knows best. I am, formally, a River committer, yet
I'm (very!) far from changing a single line of code. Heck, I did check
out the repo just to make sure that there were no obvious legal
issues. And I'm not going to vote on technical issues, no matter what:
all you will be seeing from me are abstains or, at most, +-0s. I know
where I stand, I know what my role is, I know if and when I can talk
about the codebase (never, for the time being) or vote about
legal/community issues (always).

Side note: I grew up as a commiter in Cocoon-land which, as some of
you may know, is a highly complex beast, very modular and with a lot
of different technologies involved. When I was an active developer, I
was following a few modules, where I felt confident and knowledgeable
enough to directly commit code. Of course from time to time I had to
chime in someone else's realm, where I possibly knew the big picture
but  I was definitely a complete ignorant about the actual
implementation and potential impact of my changes. In such cases, I
resorted to posting to the mailing list, possibly with a
proposal/diff, and wait for a green light from the "gatekeeper", that
is someone I knew was knowledgeable enough. Think of it as an
informal, community-oriented, RTC in a CTR environment. And believe
me, it just works: when meritocracy is at work, committers aren't just
people with technical skills, they know how to work within a
community.

I think River needs to recreate such an environment. And this is why I
see a lot of slippery slopes in introducing control-based processes
that don't take reciprocal trust into account. This is not to say that
RTC is bad in itself: it might work as an excellent tool to ensure
control where control is key (stuff like backports, security issues,
et al), just make sure it's there for the correct reasons.

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