geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anita kulshreshtha <a_kuls...@yahoo.com>
Subject Re: [VOTE] Geronimo Development Process
Date Tue, 12 Sep 2006 00:54:07 GMT
[X] +1 CTR with documentation guidelines
   
   I concur with David.

Thanks
Anita

--- David Jencks <david_jencks@yahoo.com> 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)
> 
> 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
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Mime
View raw message