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
