Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Cc: Stefan Fritsch <sf@sfritsch.de>
Message-Id: <C14116F3-E853-4C56-A39B-93453654B55D@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: dev@httpd.apache.org
In-Reply-To: <4C080DEE.2070409@rowe-clan.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: What's next for 2.2 and 2.3/trunk?
Date: Fri, 4 Jun 2010 01:51:57 +0200
References: <E678BC45-95F3-460B-A2CA-47880601EAB8@apache.org>
 <201006031858.25927.sf@sfritsch.de> <4C07E809.3000907@rowe-clan.net>
 <201006031959.44615.sf@sfritsch.de> <4C080DEE.2070409@rowe-clan.net>

On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote:

> It would be, but it's necessary.  The ASF is a collaborative  
> environment;
> unreviewed code should not released, even when the authors are  
> committers.
> A major patch like this hitting svn, without previous review, makes  
> our
> fellow committers' eyes glaze over.
>
> If there is not positive feedback from two reviewers, this code does  
> not
> belong in trunk/.  As a committer, you are *free* to create your own
> sandboxes in svn to demonstrate code changes, if that helps attract  
> the
> necessary review.

What you're describing here is review-then-commit (RTC).

If we want trunk to be review-then-commit then we must make a decision  
and make it review-then-commit. If trunk is to remain commit-then- 
review (CTR), then people must be free to commit, then have people  
review.

We cannot continue with this weird "limbo" situation where trunk is  
officially CTR, but unofficially RTC, because you have to check first  
on the list before committing anything, and you're too scared to  
commit anything because you're scared you're going to offend somebody  
who believes they should have been consulted first before someone  
commits to a CTR branch.

The reason CTR is ideal for trunk is because the consequences of the  
rest of the project being too busy to review the code, is that the  
code is accepted without dispute. This produces a clear incentive to  
make sure that the rest of the project reviews code. It's really easy  
for the rest of the project to go "I don't care about feature X, so  
I'll ignore reviewing that proposed code, I'm too busy". Under RTC,  
progress slows, people get fed up waiting for other people to review,  
progress stops, project dies.

Having said that, RTC is entirely appropriate for the stable branch.  
Here the point is stability - we don't want progress, unless the  
progress is justified through the agreement of at least 3 other  
people. Progress slows, but progress doesn't stop, because the person  
writing the code can always wait until trunk becomes the next stable  
version.

We've been doing this like this for over a decade, and it has worked  
really well. If you want the policy to be changed, argue that the  
policy should be changed. But do not try and apply a pseudo-policy on  
top of the already established ASF practice of CTR, it's not fair to  
our contributors.

Regards,
Graham
--