geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject [SUMMARY] Proposed Geronimo Development Processes
Date Wed, 06 Sep 2006 20:34:13 GMT
Three models have been proposed for the Geronimo development process.  
I've attempted to summarize the proposals, below. Assuming that I've  
capture the essence of the proposals accurately, I'd like to put them  
to a vote.

If I've misrepresented a proposal, my apologies, and let's fix it  
here. I'd like a vote thread to be, well, a vote thread... ;-)

1. Relaxed RTC
2. RTC with Lazy Consensus
3. CTR with documentation guidelines

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 (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.

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