Re: development process

[Craig L Russell]

Hi Bob,

On Aug 30, 2007, at 1:54 PM, Bob Scheifler wrote:

Gianugo Rabellino wrote:

maybe it's my non-native English skill, but I kinda feel like my
messages could have been taken as confrontational

Not at all. It's much more likely that I'm seen as confrontational.

I'd have to agree. One of the big difficulties in Apache is that it's a big umbrella that contains a number of projects that are quite autonomous, thank you very much. And once a community is comfortable with itself, it doesn't always feel that it is the community's responsibility to go and fix all the dead wood and incomplete branches of the foundation's documentation. So you have lots of stuff incompletely documented and in some places, conflicting documentation. But rather than poking at the holes in the structure (we already know it's not perfect), people trying to learn the Apache way should try to grok by reading as much as possible and then asking questions. And then take the questions and see if that bit helps to clarify.

On the other hand, there are no further gates once you
get to be a committer, and this is I think a major point in getting
people involved.

(when you want RTC to kick in).  It confuses me.

You write that as an absolute, yet follow up that there are many exceptions

Maybe this will help: Each community has their own rules. CTR and RTC are suggestions for starting points that communities can use to make their own policies. The incubator exists to help communities understand enough about what others are doing to be able to establish their own policies.

What I'm saying is
that the default is CTR, with (admittedly quite a few) exceptions.
Note, however, how the exceptions are geared towards ensuring that

track progress. This is where RTC clearly shines.

important stuff happens with a strong community oversight and a way to

For me, always-RTC is a simpler process to remember and execute,
imposes little additional overhead, and yields better code stability.
Just my $.02.

The main point here is that in Apache, the code isn't the main thing. There's lots of high quality open source code that exists outside Apache and will never become an Apache project. In Apache, the community is the most important aspect of a project. Committers are community members first and coders, documenters, and evangelizers second. The more barriers you put in front of the code the harder it is to build and sustain a community.

Here is what you don't seem to get, so I'll try to explain it again:
the technical factor is just one of the criteria for committership,

just write docs yet have access to the whole tree. We also have a
committer (Matthew Langham now emeritus) who never provided a single
line of code, but was extremely instrumental in Cocoon success and
advocacy, and probably one of the most "committed" persons of the
project. All those guys have in theory enough karma to nuke the
repository away, but we trust they won't and, in case they just go
mad, we know we can always revert.

there is much more to it. In Cocoon we have quite a few committers who

I do get it.  All I'm saying is, since you're so trusting, there's no

trust them not to abuse the privilege.

downside to always granting karma to all codebases, because you clearly

This sounds like a reduction ad absurdum argument.

Part of the Apache way is to grant privileges to community members that are necessary to their level of participation and responsibilities. While I personally have commit rights to several parts of the code base and web site, I don't have rights to the entire code base and site. There are parts of the code and site that I have commit rights to and never commit to because they're outside my domain of expertise and/or interest. Segregation of privilege is a central tenet of a secure infrastructure. So are you serious when you say " there's no downside to always granting karma to all codebases, because you clearly trust them not to abuse the privilege"?

Trust is the key here: a committer is a *trusted* member of a
*community*, and the demarcation line isn't quite the codebase, but
rather the community behind it.

I'm having a hard time parsing this particular bit.

In that line of thinking, there seems no reason not to treat all
of ASF as a single community.

Enough of my raving, I cease this line of discussion now.

Craig

I'd really like it if you can try to understand Gianugo's comments, because they reflect my view of Apache as well. It's difficult for me to tell whether your comments are "I understand the Apache way and disagree with it" or "I don't understand the Apache way and am trying to understand".

- Bob

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature