+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] > >
