+1 RTC is a good idea for release and fixes.
Let's make use of RTC for release and CTR for more experimental code. 2007/9/21, jean-frederic clere <[EMAIL PROTECTED]>: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
