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: domain of jak-tomcat-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@tomcat.apache.org
From: "Bill Barker" <wbarker@wilshire.com>
Subject: Re: Review model take 2
Date: Wed, 19 Sep 2007 19:55:32 -0700
Lines: 76
Message-ID: <fcsndb$6td$1@sea.gmane.org>
References: <46F010DB.6000704@apache.org> <46F07D29.5060006@hanik.com>
 <46F0C723.5070305@gmail.com> <46F0DAAB.2020908@apache.org>
 <46F0E4EE.6050606@gmail.com> <46F13519.4050208@apache.org>
 <46F13ABB.2060403@gmail.com> <46F1B233.3050205@rowe-clan.net>
Sender: news <news@sea.gmane.org>


"William A. Rowe, Jr." <wrowe@rowe-clan.net> wrote in message 
news:46F1B233.3050205@rowe-clan.net...
> jean-frederic clere wrote:
>>
>> Now for me that just makes another chapter in the "STATUS" file:
>> "PATCHES being discussed". After a week those patches should be accepted
>> or reverted. Reverted patches and corresponding discussions should stay
>> in the "STATUS" until a solution is found. I would keep a passing margin
>> of +3.
>
> A higher bar to add a feature than to release the software?  Plainly 
> absurd.
>
> Majority is more than sufficient for almost any decision (more + than -)
> so long as you have at least three affirmative votes.  The only exception
> would be to undoing the decision of the PMC, such as booting a person from
> the project or 'unreleasing' a release (not that this would make any 
> sense).
> Those sorts of decisions *need* a supermajority (60 - 75% or even 
> unanimous
> decision, depending on what rules the committee follows) to undo what the
> majority had settled on before.
>
> That is unless you plan to shutter the project, which is what much of this
> discussion seems to be about.  Set up as many obstacles to changing 
> Tomcat,
> until Tomcat stagnates entirely, and surrenders to that Glassfish thing?
>
> If the project wants to remain relevant, it needs a healthy community,
> which means attracting instead of repulsing people, and it needs.   And
> it needs to provide an opportunity for people to innovate, not many of
> the folks here suck on the corporate tit for their camping at Tomcat, and
> are "happy" to do allot of nothing.  Creativity is the energy behind the
> success of ASF projects.  Deny your contributors the opportunity to solve
> problems creatively, and you might as well hang out the "Closed" sign out
> on the http://tomcat.apache.org/ page already.
>
> All that said, the topic of "no more trunk" came up at the board meeting
> today.  I gave a very brief background and suggested that some of the
> renewed interest by folks who had been silent throughout the Filip-Remy
> trunk war is a hopeful sign; with renewed interest the project is very
> likely to be able to manage itself successfully through these personal
> and stylistic disagreements; the board is satisfied to see the project
> try to work out these issues themselves as long as development once again
> is encouraged.
>

TC 4.1.x and TC 5.5.x represented major changes to the core API, and 
resulted in much more stable Tomcat code.  There is no such issue for TC 
6.0.x (just a disagreement on the comet API, which we have already dealt 
with, and decided to let software-darwinism take it's course).  Thus, there 
is really no reason for a "trunk" at this time, at least until the Servlet 
3.0 spec comes out.  If somebody wanted to make a [PROPOSAL] for major 
changes to the core TC 6.0.x API, then I can see setting up a "trunk" again. 
But there is no such animal lurking at this time.

> But without reestablishing a method for the committers to innovate, or
> with continued/renewed territorial behaviors, this issue will likely
> be noticed again by the board a few months from now as an issue in need
> of a solution.
>

I maintain that there is currently a very small barrier to "innovating" on 
Tomcat.  We had one innovation that was shown to have a big whopping 
security hole in it, so it was withdrawn until a better patch can be made 
(i.e. the system worked).  There were people (myself included) that would 
have preferred a modular patch (e.g. with httpd, I can configure it so that 
mod_alias isn't included with a few small edits, but the patch in question 
didn't allow for that, which was the complaints).


> Bill 


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