Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 04 Sep 2007 08:03:39 -0400
From: Ronald J Mann <Ron.Mann@Sun.COM>
Subject: Re: development process
In-reply-to: <46D6DFA9.4040005@cheiron.org>
Sender: Ron.Mann@Sun.COM
To: river-dev@incubator.apache.org
Message-id: <46DD499B.2000306@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <30993F0A-4C88-41FD-A3D0-8853484931E8@sun.com>
 <46D51410.3080609@cheiron.org> <46D5D130.80002@Sun.COM>
 <46D67955.2010003@cheiron.org> <46D6A492.3000907@sun.com>
 <46D6DFA9.4040005@cheiron.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060727


Mark Brouwer wrote On 08/30/07 11:18,:

>Ronald J Mann wrote:
>
>  
>
>>I don't think this means that the entire collective need vote on any and
>>all changes prior to committing, which I agree seems idiotic.  I think
>>what it does mean is that any putback requires a second committers
>>public assent.
>>    
>>
>
>Hi Ron, does this mean that you also see value in Bob's process idea or
>do you consider RTC as described at the ASF website as sufficient?
>  
>
Sorry for the delayed response...(it had nothing to do with you putting
me on the spot with Bob ;-)   was away on personal issues for the past
few days). This is a difficult question for me.  I'll start by saying
that I'm not a big fan of process, I prefer common sense, unfortunately
once there are a dozen or so people involved sense is rarely all that
common.  As a team here we have and to some extent continue to struggle
with the notion of RTC vs CTR as there are times when one wishes to
innovate rapidly and therefore is willing to risk more of a stability
hit, whereas there are others when correctness is the primary goal. 

As I read the ASF rules, I think we should rule out the notion of group
voting on individual code changes as far too heavy handed.  Others have
mentioned the quality of the the minds involved on this project, most of
whom I know well and I'm perfectly happy to trust any given pair of us
to do the right thing. As such, I'm content to have the notion of RTC
mean that to commit a change requireds that the comment contains a
reviewed by reference.  In the case where a change is so trivial,
dotting an i or crossing a t, I'm aware that its a pain to have to find
someone to do so, but frankly a quick post to the list and it can be
handled by anyone quickly. If the changes are deep and heady, its almost
unimaginable to me that anyone would want to commit without at least one
good pair of eyes perusing the changes first anyway.

I alluded to the Sun team's own internal philosophical struggles with
RTC vs CTR.  I believe in the end after many years of angst and debate,
we've simply come to the conclusion that the fastest most reliable path
to nirvana is to RTC. I will admit, when I first joined the team I
misinterpreted the use of RTC as a bit of a personal slight on my
abilities.  I'd urge committers not to view it as such. I think we've
found that RTC can contribute positively to team building, whereas CTR,
which generally occurs after problems are found, can have the opposite
effect.  Yes, there are times when RTC is a perfunctory operation and
largely unnecessary, however in these moments, the cost of oversight is
very small and goes largely unnoticed.  Ongoing stability is dead
critical for making any progress with this body of code and IMO, a
review by a second committer prior to putback is a necessary evil. 

To be clear, my comments here are around changes to the underlying
implementation which are presumed to have no/insignificant impact on the
specs. I'm a tad confused on the who owns the spec issue, but assuming
this group has the authority, full blown spec changes I believe demand
that the full group vote and would certainly demand RTC as well.

=Ron=