tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Review model take 2
Date Wed, 19 Sep 2007 08:39:31 GMT
+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" <costin@gmail.com> wrote in message 
news:96e4b5230709181502w6610e261h124dd45631fa33f0@mail.gmail.com...
> +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 <remm@apache.org> 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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message