tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: Review model take 2
Date Thu, 20 Sep 2007 02:19:21 GMT
I agree that a simple majority should be enough for any API change or any
but I don't think this was the spirit of the proposal.

What I see as a problem is not involving the community in the decision
making about
basic features.

Let's make it clear - adding new features or replacing/improving any
component in tomcat
should stay CTR and should be encouraged and supported. Anyone can create
Valves, Connectors,
Jndi implementations, class loaders or almost anything else that can be
plugged into tomcat
via config file - and a change to add more hook points shouldn't be hard to
get in.

However - for new features that want to be bundled with tomcat, or for
important or
controversial changes ( defined as 'no consensus' - and one person in
disagreement means
no consensus ) - a majority vote should resolve the question and avoid any
personal or one-on-one

Consensus is simple to determine - and so is lack of consensus for any
feature. If Remy and Filip
( and all other committers who care about something ) are in consensus -
done. If there is
doubt - involving and asking more people seems the right solution.

I think it is a big mistake to use the sandbox as a way to avoid
confrontation -  or to waste time
debating subjective things like what is better among 2 not-so-obviously bad
solutions ( which is
what causes most hurt feelings ). Implement any feature  you want in a
module, pack it as a jar
 with instructions on how to use it, get 3 +1s to release it - and after it
gets some testing and
traction - request it to be part of standard distro or the default
 Easy, no conflicts needed, good for both tomcat and the feature itself. If
someone else can
implement it in a better way - new vote will get the other one.


On 9/19/07, William A. Rowe, Jr. <> wrote:
> 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 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.
> 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.
> Bill
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message