So what about RTC for core and CTR for extensions in incubator land ? 2007/9/21, Costin Manolache <[EMAIL PROTECTED]>: > 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] > > > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
