I agree that a simple majority should be enough for any API change or any feature, 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 fights. 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 JNDI/Connector/ClassLoader/etc. 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. Costin On 9/19/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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 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. > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
