tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Gomez" <henri.go...@gmail.com>
Subject Re: Review model take 2
Date Fri, 21 Sep 2007 08:45:08 GMT
+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 <jfclere@gmail.com>:
> 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: dev-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message