tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: Review model take 2
Date Tue, 18 Sep 2007 22:02:49 GMT

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.


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:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message