tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Review model take 2
Date Wed, 19 Sep 2007 01:36:41 GMT
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
yes, makes sense
> - 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
-1. There is a huge risk for "I simply don't like it, revert it". 
Anything that is to be rolled back, should be backed up by a technical 
reason. So in this case, how do you define "it hinders concurrent work". 
Either we do RTC or we don't, but having a vague definition in between, 
doesn't make sense.
> 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.
The community has always been open to technical discussions, it's the 
countless vetoes without technical justifications that became the major 
pain in the rear.
> 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.
I don't really see the need of doing our own version of a semi RTC, 
either we do RTC on release branches and CTR on trunk.
So I'd be -1 on this, the main reason, is that the definitions are not 
common nor defined within the larger ASF community, hence the vagueness 
would only arise for more debates.

> Rémy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message