river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Waldo <Jim.Wa...@sun.com>
Subject Re: development process
Date Fri, 31 Aug 2007 11:58:41 GMT
Mark--

What I was trying to state was far simpler, and far less rule driven.  
I'll try again.

We have a set of committers. They are all senior engineers, and I  
trust them to be adults. If they are committing something that came  
from members of the community that aren't themselves committers, then  
I trust that the code will have been throughly reviewed by the  
committer. If they are committing something that they wrote  
themselves, then I trust that they have their own mechanisms for  
insuring code quality (since the ability to produce good code is the  
reason that they are a committer). It might be that they have a set  
of others that they use as reviewers for their own code. It may be  
that they are particularly through in their testing. It may be that  
they shoot from the hip, and do it very well.

Different people have different ways of reaching the same outcome. I  
worry when we try to get everyone to use the same procedure; it is a  
way of limiting the diversity of the community. I am also worried  
about the implicit notion that we can't trust the other committers  
and need to have some process so that we can check on each other  
before the fact (rather than after).

This does mean that someone could behave badly. We have various forms  
of recourse, from backing out a particular commit to revoking  
committer status. Trust, but verify.

So when I say that I would have my code reviewed, the statement is  
confessional and tells you how I do things. It is not meant to be  
prescriptive and tell others how they should do things. How someone  
produces good code (or good designs) is up to them...

Jim

On Aug 31, 2007, at 4:38 AM, Mark Brouwer wrote:

> Hi Jim,
>
> Jim Waldo wrote:
>
>> So let me suggest that we start with a notion of trust, and adopt  
>> a CTR development process. More to the point, let's try to do  
>> something with the project, rather than continually debating how  
>> we are going to do anything...
>
> From your posting I sense that you think reviewing before  
> committing is
> essential as you say "I doubt seriously that I would ever commit
> anything to the project without having it reviewed, either by one  
> of the
> other committers or by someone who I thought could understand the code
> (no matter how complex). I trust the other committers on the  
> project to
> do the same.". In the end you even use the 'moral pointy finger' [1] I
> recognize from my parents ;-)
>
> You say start using CTR but with the expectation it has been reviewed
> before it appears for commit, so in fact you suggest RT-CTR. So that
> means a contributor must look for a reviewer, in my case this would
> likely resort into an open cry into the mailing list as I'm not in the
> luxury position I have qualified people around me that have time for
> that. So I would like to know the field experts (I know a few after  
> all
> those years, but still have no oversight for the complete system) and
> therefore it would help me to have a list of people qualified to  
> review
> per component. I therefore fail to see why not formalize this  
> behavior,
> it is a clear signal to others the way we work (confusion is often a
> reason for frustration or as Bob pointed out disincentive to
> participate). For potential users (those who only download) who have
> read our policies it might even give a hunch about how much we care
> about code quality. With JIRA we can probably modify the process
> flow to assist in the RTC policy.
>
> As an aside, reviewing before committing is not that common for  
> many of
> us. The way the Jini team worked probably scored very high in the
> Capability Maturity Model, but many potential committers (including  
> me)
> have worked in environments where shooting from the hip is often the
> norm. And some can shoot very well from the hip, so if you are used to
> that and have been reasonable successful it can and will be  
> confusing to
> be 'morally pointy fingered' by you while the official policy is CTR.
>
> As has been expressed by the mentors social skills are very important
> and I think it is harder to develop the right social skills for the
> River community if the expectations are different from the written
> policies. In my experience just lurking on a mailing list is not a  
> very
> effective way to find out how one should behave as often you see many
> deviating behaviors and various tones and that is because between  
> people
> that know each other fairly well adapted ways of communicating  
> start to
> arise which might blur reality for others. It takes quite a while  
> to be
> able to apply all the right filters. A good example of this is Gianugo
> who felt he was being confrontational against Bob, while in fact he  
> was
> facing this http://www.gizmology.net/images/tank11.jpg, a lot of steel
> armor but inside a nice guy :-)
>
> Also I think there is plenty of time left to debate these things while
> AR1 is getting out the gate. I find it more frustrating that we can't
> properly finish these kind of discussion without resorting to  
> "let's try
> to do something with the project, rather than continually debating how
> we are going to do anything...". If somebody finds something a
> non-discussion, just don't participate. In this case I think most
> initial vocal committers so far lean towards RTC, so I think we should
> explore a way that would make it workable without going against ASF
> policies.
>
> [1] probably there is a proper English saying for that, if so let me
> know that way I can use if more often and correctly :-)
> -- 
> Mark
>


Mime
View raw message