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]
