Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <46E17FF9.3080107@hanik.com>
Date: Fri, 07 Sep 2007 10:44:41 -0600
From: Filip Hanik - Dev Lists <devlists@hanik.com>
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>
In-Reply-To: <46E03EBC.2050500@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

bottom line is that
1. moving trunk to sandbox
2. trying to implement a semi RTC

both do nothing but hurt Tomcat moving forward, and falling further 
behind in the servlet container space.

The whole debate that has risen up, is only based on conjured up  
supposed breakage of the CTR  model that never happened, and the mailing 
archives and SVN prove it.
Anyone with interest and time to do the research, would come to the same 
conclusion.

I'm extremely sad and bothered that it's led to this, and that we 
haven't addressed the issue for what it really is. But this has happened 
in the past, and hopefully we will survive this too.

I've received several personal support emails about the incident, but as 
long as people don't speak up in public, it's gonna have to go down in 
history as one of those events that in previous history of ASF Tomcat 
caused a fork, simply because folks were being cornered and not getting 
any leadway to continue development in a forward direction.

Another fork at this time is not an option, this community needs to heal 
up, speak up, and focus on forward development, not on trying to 
restrict and control everything tighter, it is the *control* factor that 
got us here in the first place. Its a community project, it is not for 
an individual or for a corporation to try to control the code base!

Filip


Mladen Turk wrote:
> Remy Maucherat wrote:
>>
>> To give an idea, "tis" could mean:
>> - API changing patches (any protected or above signature change)
>> - code changes in the critical path (for example, code which gets 
>> executed on each HTTP request)
>
> Fine.
>
>> - any other commit for which a committer asks for the RTC procedure 
>> should be rollbacked if it hinders concurrent work, and go through 
>> the RTC procedure
>>
>
> This looks like a conditional veto that can be voted over. Perfect!
> IIUC it means that instead veto one asks for a vote (+3 votes), right?
> Looks like RTC on demand, that would require some sort of lazy consensus.
>
> Regards,
> Mladen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


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