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 (nike.apache.org: local policy)
Message-ID: <46CC3F64.4020200@hanik.com>
Date: Wed, 22 Aug 2007 07:51:32 -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] Send trunk to the sandbox
References: <20070813181349.791471A981A@eris.apache.org>
 <fabbh8$2gb$1@sea.gmane.org> <46CA1D3B.1070204@apache.org>
 <46CBCD53.7080500@apache.org>
In-Reply-To: <46CBCD53.7080500@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mark Thomas wrote:
> Mark Thomas wrote:
>   
>> Bill Barker wrote:
>>     
>>> I'm so tired of this thread, so let's settle it once and for all.  I'm 
>>> backing Remy's suggestion to send the current trunk to the sandbox:
>>> [X] +1 Let's end the revolution
>>> [ ] +0 What revolution?
>>> [ ] -1 Viva the revolultion
>>>       
>> This applies to this proposal only. Other changes should be proposed
>> in other threads.
>>     
>
> Expanding on what I said on private@ as I see no reason for it not to
> be part of the public discussion...
>
> I don't see a need for a separate 6.0.x and 6.1.x development at this
> point. I have yet to see a convincing technical argument that there is
> something sufficiently new and/or different to justify this overhead.
> There is enough work to do to maintain 4.1.x, 5.0.x (which we aren't
> doing a great job of and I am several months past my promise to do a
> security release for 5.0.x), 5.5.x and 6.0.x without adding yet an
> other branch.
>
> Simply, trunk should never have been called trunk, it is a branch. It
> should be moved to 6.0.x/branches/whatever
>
> In terms of moving forward, merge the changes in 'trunk' to 6.0.x.
> Ideally this should be done commit by commit or groups of related
> commits so we can discuss each of the additions if necessary. If any
> attract a veto or are viewed as too experimental etc they can stay in
> 6.0.x/branches/whatever until the issues are resolved or that feature
> is abandoned. My expectation is that 99% of what is in /trunk can move
> to 6.0.x/trunk with little or no debate.
>   
your points are completely valid, here is the thread for trunk
http://marc.info/?l=tomcat-dev&m=117940240523993&w=2

the idea, discussed in this thread, was to freeze 6.0 API all together, 
and continue with new changes in trunk, everyone was in agreement. and 
if comet was the culprit, that feature can be pulled out, I've must have 
said that 3 dozen times now.

just the history of how we got to where we are at.

At this point, I'm beat down by this argument, I'm getting vetoes on 
other areas just cause folks don't properly look over the patch 
submitted and are on a pure vendetta, it's too much of a personal head 
ache to fight that kind of attitude, that has no technical backup.

do whatever you want, I'll tag along, my objections have been noted, 
that's good for now.

Filip

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