+1 I agree with Costin here. If it can't be added/removed as a pluggin, then it doesn't belong in the default Tomcat distro.
"Costin Manolache" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > +1 > > I think one exception ( or maybe something that should be easily > fast-tracked ): > - adding new hooks to allow such features to be developed and plugged in > as > separate modules > > For any new feature or bigger change to a component that already has a > plugin mechanism ( connector, etc ) - > it would be better to have it developed as an optional module ( i.e. not > included in the default build, but > as a separate jar that can be easily installed in lib/ ), and after it > gets > released, tested, etc - it could > be moved to the official distro based on a similar vote. > > That would mean that any 'itch scratching', new feature or major change > can > still be done in CTR mode, > in the main branch (instead of sandbox), and be usable. > > Costin > > On 9/18/07, Remy Maucherat <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> Another more precise draft. >> >> Patches which would go to review would be: >> - API changing patches (any protected or above signature change) on APIs >> which are accessible to the user either from confirguration or >> programmatically >> - any other commit for which a committer asks for the RTC procedure >> should be rollbacked if it hinders concurrent work or is to be included >> in a release tag, and go through the RTC procedure >> >> The RTC procedure would include a STATUS file in the Tomcat svn listing >> all pending "up to review" changes. A successful vote with a +3 margin >> is required. A patch can remain under review for as long as the >> committer wishes, and it should be allowed to freely "advertise" and >> discuss the vote. >> >> The idea would be to force a consensus for commits which could have >> significant implications, and help stage technical discussions (rather >> than discussions about the validity of the disagreement). It would >> introduce a small delay for committing certain patches and a minor >> slowdown for development pace in theory, but in practice I've noticed >> conflicts waste a lot more time. >> >> This would also mean it is possible to make a change that a number of >> committers oppose (possibly, would veto) if enough committers are in >> favor of it. >> >> Rémy >> >> >> --------------------------------------------------------------------- >> 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]
