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 Thu, 20 Sep 2007 17:59:46 GMT
It could be a simple as (as opposed to trying to reinvent the apache way)

1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC or CTR
2. We'll all pay more attention to discussing a change prior to SVN 
commit whether it is RTC or CTR
   But we don't need a "new process" for this
3. Bring back trunk as CTR, again, following the advice in step 2 (yes, 
me included)

And have it all over with. The reason I'm opposing here is that the 
tomcat community is trying to (re)invent a new development process. 
Trust me, if there was a better way, someone else would have probably 
thought of it, it's not like we are the originators and demi gods of 
The reason we are at the ASF, is to piggy back on the ASF ways, as 
simple as that.


jkew wrote:
> Folks,
> I'm somewhat on the outside looking here, so I'm probably going to be 
> a little naive:
> 1. It's really time to come to a conclusion on this, before people get 
> too exhausted and give up.
> 2. Ideally everyone should compromise a little on a solution, but this 
> doesn't always happen.
> 3. People really hate making decisions that are going to be set in 
> stone, especially when they are emotionally involved.
> What about a trial period of three(or 'n') months for a review model? 
> People who hate the review model may be more willing to compromise a 
> bit more for a 'test' phase. The review model does not have to be set 
> in stone, but we do need something in place until people can calm down.
> 1. Those who compromise more than others should be willing to give the 
> new system an n month trial period to allow a new process a chance to 
> settle w/o constant criticism.
> 2. Those who compromised less should be willing to change the system 
> after the n month trial period.
> Whether it is Remy's plan or another, it is really important to codify 
> some process at this point. I would rather not waste any more bits on 
> this. I hate the idea of proposing anything at all in the middle of 
> this discussion, but we have got to get past this.
> -John
> 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:

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

View raw message