river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: development process
Date Thu, 30 Aug 2007 22:01:08 GMT
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.
>
> You write that as an absolute, yet follow up that there are many  
> exceptions
> (when you want RTC to kick in).  It confuses me.

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
>> important stuff happens with a strong community oversight and a  
>> way to
>> track progress. This is where RTC clearly shines.
>
> 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,
>> there is much more to it. In Cocoon we have quite a few committers  
>> who
>> 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.
>
> I do get it.  All I'm saying is, since you're so trusting, there's no
> downside to always granting karma to all codebases, because you  
> clearly
> trust them not to abuse the privilege.

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.

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

Craig
>
> - Bob
>

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


Mime
View raw message