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