I agree with Kevan.
Thanks,
Aaron
On 9/6/06, Kevan Miller <[EMAIL PROTECTED]> 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 ***
