Filip Hanik - Dev Lists wrote: > 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
Every one should why Sun had forked from Tomcat... I am sure a RTC on stable branches would have prevent it. None needs a toy for production. Why do you think Apache httpd is still the best open source WEB server (see http://www.infoworld.com/slideshow/2007/09/114-best_of_open_so-5.html)? - Because stable branches are really stable why are they so stable because they use RTC. > 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 That is not a new process what we need is to define what to do if the consensus doesn't come out when the review ended in "please stop we need to discuss that commit/feature/fix". > 3. Bring back trunk as CTR, again, following the advice in step 2 (yes, > me included) yes we need a place for common innovation. > > 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. Again something worked wrong you can say it is your fault (and tell it to everyone (including Remy)) but nothing prevents that happening again. Should we define a process to prevent that? For me yes. Cheers Jean-frederic > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
