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