Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <46E69EB8.2030903@apache.org>
Date: Tue, 11 Sep 2007 15:57:12 +0200
From: Remy Maucherat <remm@apache.org>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: [VOTE] Make released versions RTC
References: <46DD1CFD.80908@gmail.com>
	 <FA97C969-28CF-44D6-BD9D-6529AADB801D@jaguNET.com>
	 <46DD822C.8060807@apache.org>
 <46DDF831.7090506@hanik.com>	 <46DE7C27.7020202@apache.org>
	 <DAE8E1AD-4CE9-426C-B26E-DD4A42FF9D8C@jaguNET.com>
	 <46DEB18A.6050403@apache.org>
 <6291fc850709050831q185c717fj83674cbe86cee47a@mail.gmail.com>
 <46E034F6.40108@apache.org> <46E03747.2060600@apache.org>
 <46E03EBC.2050500@apache.org> <46E52F49.2070300@apache.org>
 <380EC0EA-E151-47EF-9860-3317C84E7B45@jaguNET.com>
 <46E5AD7E.1090807@apache.org>
 <CAD61CFD-6F63-4844-B221-FE8CA013EA53@jaguNET.com>
In-Reply-To: <CAD61CFD-6F63-4844-B221-FE8CA013EA53@jaguNET.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Jim Jagielski wrote:
> On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
> 
>> The main idea is that since there's only one trunk branch, there 
>> should be agreement on APIs and important topics to proceed
> 
> ++1. So let's start that now. Since there is not agreement on APIs,
> how do we proceed from here? Or, in other words, how do achieve
> agreement on APIs?

Actually, there's no need for a full agreement for a reviewed patch 
(from what I've written about a limited CTR mechanism): it's a need to 
pass the vote with a +3 margin. This means most people care and agree 
with you, but this does not mean it's a unanimous vote either.

If the community is evenly split and nothing moves, then there is never 
going to be a solution at Apache except eventually agree to fork the 
project.

If people don't care enough to vote (as long as the review mechanism is 
infrequent enough and not too inconvenient), then I think there's a 
problem with the patch or the way it was presented.

> Shame that you think that various "useless rules" are those rules that
> have been used by the ASF and numerous ASF projects for years and
> years... that these "useless rules" are those which Incubator
> podlings must understand and utilize in order to become a "real"
> ASF project...

This statement is a bit too aggressive, since it seems obvious that if 
there's a disagreement, you cannot keep on developing in an official 
branch like trunk, but that a proper proposal should be used instead.

CTR for API changing patches (and for patches for which committers think 
is needed) works pretty much like the usual proposal mechanism. However, 
it puts down the rules in black and white about what sort of commit is 
concerned by them and how it happens.

R�my

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org