"William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
