[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Trust and Review was Re: cvs commit: httpd-2.0 STATUS
From:       Justin Erenkrantz <justin () erenkrantz ! com>
Date:       2003-02-27 16:41:58
[Download RAW message or body]

--On Thursday, February 27, 2003 12:53 PM +0000 gstein@apache.org wrote:

>   +               The problem here is that R-T-C expresses a fundamental
>   +               DISTRUST of your peers. We had problems stabilizing the
>   +               code simply because there are numerous interests in the
>   +               codebase, and those are not fully compatible. With the

It's also the fact that I have no way of knowing whether my fix is perfect - I 
might think it is, but I just won't stake my reputation or this group's 
reputation on it.  Actively enforcing peer review allows some confidence that 
at least two other people agree with the change.  It's a way of backchecking 
not as a matter of distrust.

In fact, I'd say it is the reverse: R-T-C mandates a trust in your peers that 
they are able and willing to understand the code.  Creating code in isolation 
without anyone else understanding it is harmful.  We're developing this server 
together.  We have a number of places in our code that there may only be one 
or two people who fully understand it.  I don't believe that is goodness on 
our parts.  If we enforce code review, then it makes it such that others start 
to get exposed to other areas they may not have been exposed to before.  That 
is the best way we can deal with people leaving and abandoning 'their' code.

Even the most trivial 'common sense' commits can generate essential feedback 
that a single developer overlooked.  I can only perform limited testing on it 
with my own platforms, compilers, etc.  I may be too close to the problem to 
get an accurate view of what the fix should be.  I view peer review as a 
safeguard and a mechanism to show the community that we are doing our best to 
produce the highest-quality releases that we can.

The fact is that with C-T-R, we hardly ever did R.  The sheer volume of 
commits was just too much for lots of developers - AIUI, this is why we 
abandoned R-T-C not because anyone in the Apache Group wanted to.  If we all 
weren't so damn lazy, C-T-R might have worked in producing stable releases.  I 
just don't believe that materialzed.  Our release quality has been reducing 
for a long-time because we haven't been relying on what made us good: 
'high-quality well-tested releases.'  -- justin
[prev in list] [next in list] [prev in thread] [next in thread]