I have a strong feeling this is turning again into a debate over words, arcane details and abstract concepts ( 'what is a trunk' and how to increase innovation )
The real issue is quite simple, and not having a trunk or all the new process seems more like an attempt to solve it: We want tomcat evolution to be done by consensus or at least majority, not by one individual ( be it Remy or Filip or anyone else ) making decisions and changes to the core API without consultation and agreement from others ( and yes, most vetoes are probably invalid and bad - the changes are technically ok, and the veto is a blunt tool to express lack of consensus and frustration ). The whole veto / remove trunk / personal hurt feelings / CTR / RTC / process debate is just a way to avoid this from happening. Yes, we want innovation and change and contributions and all that - but that doesn't mean that anyone who can make a technically valid change ( i.e. where a veto would be invalid ) should make it - if it affects other people and it lacks consensus. That doesn't mean you can't add features ( to 6.0 or trunk or however you want to call it ), or you can't make big changes, or someone can block 'progress' or impose his own vision of progress. All those proposals evolve around how to involve more people in decision making and be as close to consensus as possible. I personally consider tomcat way overbloated - so I think I'm on the same side with Remy on voting against adding any new feature that could be done as a plugin, and I would be happy to see 'innovations' in tomcat removed from std and moved to separate plugins, until we're at the same size with jetty or other containers in the base distro. But I do understand Filip's frustration and the desire to try now things - and this should happen, not in sandbox but in 6.0 tree, except not in the core and with controlled API changes. Costin On 9/20/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > > 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] > >
