geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: [PROPOSAL] Modified RTC
Date Wed, 06 Sep 2006 17:40:57 GMT
Matt,

I liked this "relaxed RTC" proposal. However, would you be willing to
consider one slight change to it.

Could you please propose a timelimit before which the patch gets the
required +1 or atleast one -1 vote ? After the set time, if there
isn't any single "nay" vote, the patch becomes ready for commit with a
lazy consensus.

One thing that arose some confusion in the past was whether the
committer proposing the patch could count his own vote in. This needs
to be clarified too.

Cheers
Prasad

On 9/6/06, Joe Bohn <joe.bohn@earthlink.net> wrote:
> +1 to considering alternatives in addition to relaxed RTC.
>
> Joe
>
>
> Kevan Miller wrote:
> > Matt.
> > Agreed that it's time to push this issue to a conclusion.
> >
> > There seemed to be two schools of thought in the "Returning to Commit-
> > Then-Review" thread:
> >
> > 1) CTR with guidelines for documenting new function to the community,  and
> > 2) RTC with lazy consensus.
> >
> > The proposal you describe below is a third option (RTC with relaxed
> > review and PMC vote requirements). Which is fine, but I think it's a
> > new/different  proposal. I assume this was your intention.
> >
> > I propose we summarize these 3 options and put them to a vote. If we
> > feel that is fragmenting the vote, then we vote on CTR vs. RTC, then
> > refine the specific process. Comments?
> >
> > --kevan
> >
> >
> > On Sep 6, 2006, at 1:50 AM, Matt Hogstrom wrote:
> >
> >> *** Begin Proposal ***
> >>
> >> Geronimo Development Process
> >>
> >> Geronimo follows a model similar to Review Then Commit (RTC).
> >> Patches for new function are provided by developers for review and
> >> comment by their peers.  Feedback is conducted through JIRA  comments.
> >> The goal of this interaction is to solicit suggestions  from the
> >> community and incorporate their feedback as appropriate.   In order
> >> for a patch to be accepted it requires the following:
> >>
> >> * Needs to be reviewed by committers on the project.  Others may
> >> comment but their comments are not binding.  The review may, but  does
> >> not have to, include application and testing.  The goal of the  review
> >> is to understand the technical attributes of the change as  well as
> >> the assess other impacts to the project as a whole.
> >>
> >> * 3 +1 votes from committers on the project (1 of these committers
> >> needs to be a member of the PMC) with no outstanding -1 votes.
> >>
> >> * Any -1 votes need to be accompanied by a reason and a mutually
> >> agreed upon solution to the issue raised.
> >>
> >> * If the issues can't be resolved then the PMC can be called upon  to
> >> settle the dispute and make a recommendation.
> >>
> >> * Issues are generally of a technical nature.  However, issues may
> >> include other items like usability, project cohesiveness or other
> >> issues that impact the project as a whole.
> >>
> >> The goal of these guidelines is to facilitate timely communication  as
> >> well as the fostering of ideas and collaboration as well as  innovation.
> >>
> >> *** End Proposal ***
> >
> >
> >
> >
> >
>

Mime
View raw message