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 Fri, 21 Sep 2007 18:18:17 GMT
Jim Jagielski wrote:
> On Sep 21, 2007, at 1:59 PM, Jim Jagielski wrote:
>> All good points. It just seems to me that the voting should be
>> on code that, as you said, affects people. When the code enters
>> a release branch, then approval is needed. The fact that it's
>> been in trunk and has worked well and that others within
>> the PMC and dev community have played and worked with it
>> will count for something, but it is still a RTC rule. Having
>> trunk means we get consensus twice: the 1st under CTR (a lazy
>> consensus to be sure) and then when moved to release under
>> RTC.
> And again, what we are talking about is not that much
> different from Remy's proposal:
> Remy's proposal is:
>   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.
> If we simply say this is for release branches (X.Y where Y is even) then
> we pretty much just have RTC, since simple patches will get the required
> 3 +1 votes pretty quickly). In fact, Remy's comment "to be included
> in a release tag" pretty much makes it clear that what is the
> concern is what is released (the "affects other people" rule).
> If we have a trunk which is CTR, then we can also have a general rule
> that says "For API changes, patches should be done with advance
> notice under lazy consensus" ("I plan on doing this which will
> break/improve/modify the API. I plan on committing this in 3 days.
> Holler if you have any complaints")... which is a normal
> courtesy anyway. For really far reaching ones, people break
> off a sandbox, do their stuff there, and refer to the sandbox
> repo directory when giving the advance notice... (this is
> also good since it allows people to see the history behind
> the development as well).
> So I really don't see a lot of difference here...
This is what I have been trying to convey, although, much of my things 
get lost in the flame debate, mostly my fault.

the difference is in the eye of the beholder, that is why I believe 
going with the predefined rules that ASF already has, since going away 
from that leaves too much to interpretation, and it also makes it easier 
bringing in new committers, especially if they are already familiar with 
the ASF.

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

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

View raw message