It could be a simple as (as opposed to trying to reinvent the apache way)
1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC or CTR
2. We'll all pay more attention to discussing a change prior to SVN
commit whether it is RTC or CTR
But we don't need a "new process" for this
3. Bring back trunk as CTR, again, following the advice in step 2 (yes,
me included)
And have it all over with. The reason I'm opposing here is that the
tomcat community is trying to (re)invent a new development process.
Trust me, if there was a better way, someone else would have probably
thought of it, it's not like we are the originators and demi gods of
programming.
The reason we are at the ASF, is to piggy back on the ASF ways, as
simple as that.
Filip
jkew wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
