Henri Gomez wrote: > So what about RTC for core and CTR for extensions in incubator land ?
Well see the result of the "[VOTE] Make released versions RTC". We need 2 things innovation (on a common trunk) and stability on released branches. That why I made the proposal "[VOTE] Make released versions RTC". CTR didn't seem to work on the "old" trunk and we have to prevent this happening again, therefore comes the idea of a "RTC on demand". Cheers Jean-Frederic > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
