geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: [VOTE] Geronimo Development Process
Date Tue, 12 Sep 2006 02:17:49 GMT

On Sep 11, 2006, at 3:45 PM, David Jencks wrote:

>> [X] +1 CTR with documentation guidelines
>
> I'm worried that we will not maintain enough awareness of each  
> others work, and think we all need to be very vigilant.  I agree  
> with Joe that we need to review how we are doing in a reasonable  
> amount of time (2-3 months, less if there are obvious problems)
>

[X] +1 CTR with documentation guidelines

And to clarify, my proposal was actual for CTR w/optional RTC with  
Lazy Consensus, where we as a community agree RTC with Lazy Consensus  
is encouraged in the following situations:

On Aug 23, 2006, at 1:14 PM, David Blevins wrote:
> I'm inclined to say "at your discretion" where the following are  
> encouraged:
>  - Significant new functionality
>  - Significant changes
>  - Patches from Contributors
>  - Borderline "fixes" to a stable branch

This is still my preferred verbiage.

-David


> thanks
> david jencks
>
>
> On Sep 10, 2006, at 9:23 PM, Kevan Miller wrote:
>
>>
>> This is a vote to determine the development process the Geronimo  
>> community wishes to use for "trunk" development. If any  
>> modifications are needed for a "branch" development process, then  
>> a separate vote will be held.
>>
>> All votes are important. This is a community-wide issue. Please  
>> let your voice be heard...
>>
>> Choose the development process which you think will best serve the  
>> Geronimo community. I'd like to limit voting to a single process,  
>> rather than using a poll/ranking system (i.e. 1,2,3). If a clear  
>> consensus does not emerge, then we'll need to refine and hold  
>> another vote.
>>
>> [ ] +1 Relaxed RTC
>> [ ] +1 RTC with Lazy Consensus
>> [ ] +1 CTR with documentation guidelines
>>
>> These development processes are summarized below:
>>
>> 1. Relaxed RTC
>>
>> Geronimo follows a Review-Then-Commit (RTC) model.  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 with no outstanding -1  
>> votes.
>>
>> * Any -1 votes need to be accompanied by a reason (the parties  
>> should then attempt to reach 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.
>>
>> 2. RTC with Lazy Consensus
>>
>> Geronimo follows a Review-Then-Commit model with Lazy consensus.  
>> 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.  
>> A patch is accepted if:
>>
>> * 3 +1 votes from committers on the project with no outstanding -1  
>> votes and no significant, ongoing discussion
>>
>> * 72 hours pass with no outstanding -1 votes and no significant,  
>> ongoing discussion. A 24 hour warning should be sent to the dev list.
>>
>> 3. CTR with documentation guidelines
>>
>> Geronimo follows a Commit-Then-Review model. There should be an  
>> emphasis of community communication. Community-based policing and  
>> persuasion will be used to remedy any problem areas. Guidelines  
>> are not strict dogma -- common sense should prevail. Community  
>> communication is the key, not a process. General guidelines are:
>>
>> * Non-trivial changes (and certainly potentially controversial  
>> changes) should be announced on the dev list. This announcement  
>> should be well in advance of the change being committed. The  
>> community should be given the opportunity to understand and  
>> discuss the proposal.
>>
>> * Concurrent with the commit of a significant change, the  
>> committer should document the change on the dev list. You should  
>> describe what you are doing, describe why you are doing it, and  
>> provide an overview of how you implemented it.
>>
>> --kevan
>


Mime
View raw message