tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Review model take 2
Date Wed, 19 Sep 2007 08:39:31 GMT

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" <> wrote in message
> +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 <> 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:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message