On Sep 21, 2007, at 2:13 PM, Jim Jagielski wrote:
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 how about this... this is something that has been done, and
is being done, in just about every ASF project. Why don't
we vote on this and give it a time-table at which point we
review how it's worked out over the last 3 months or so
and fine-tune if and as needed?
Once we agree this is a workable implementation, we can
determine numbering aspects and initial code repo loads.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
