Will f/w board since this follows from the 'no more trunk' comment which some officers questioned. Please don't cc per-say, but feel free to f/w a relevant response to [EMAIL PROTECTED] (it's bad form to crosspost a message with both public-and-private destinations).
Bill Barker wrote: > "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote in message >> >> 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. No doubt, these were significant departures from their previous code. But, are you suggesting that there is no need for trunk until there is an idea you happen to champion? Present you with an idea that you like and half the committee might decide to permit new development again? This is certainly turning the idea of "show me the code" on it's head. To give an example oft cited on this list, httpd maintains a trunk. It might be released some day as-is, it might never be released. But it's a staging ground to prove up an idea before injecting that idea into the shipping stable version. It appears there is no such wilderness at Tomcat. Sandboxes don't cut it. It's very clear sandboxes are one-man-shows at Tomcat. As such, they go against the concept of collaborative development and don't belong at the foundation. If I misunderstand, and sandboxes are shared spaces for proving concept-not-the-programmer, and everyone is welcome at each sandbox to improve the proof of concept themselves, then my objection is unfounded. It seems the list wants very tight control on the stable 6.0 branch, so your observation that trunk is irrelevant hasn't jived since I first read this post (and I considered it's implications for a good 12 hrs). It also brings up a real question of why was it so important to 'kill trunk' if trunk, admittedly, is not relevant? >> 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). You are talking about one patch. Has Tomcat become so pathetic that there's only one example of innovation in the past /x/ months to hold up as the one true example? Let's hope the rule systems that Tomcat debates and settles on reflect the diversity of contributions, as opposed to a small handful of exceptions. The fact that the rule systems themselves are being debated points me to really wonder if there is any code debate here at all, or nothing more than a clash of personalities which "changing the rules" is the simplest solution to getting one's way? In any case, the list continues to ponder what the meaning of the branches, sandboxes etc all are, and I'll step out of this conversation (baring any truly insane proposals) while the TC core community comes to terms with how Tomcat can still prosper, and lose the perception of being a fiefdom of the chosen few. Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
