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.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
