geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: [SUMMARY] Proposed Geronimo Development Processes
Date Thu, 07 Sep 2006 16:59:53 GMT
Thanks Matt and Jason.

I'll update the proposals to remove the PMC requirement from Relaxed  
RTC.

I'm also going to update to make clear that the focus of this vote is  
trunk development. Initially, it would apply to branches, also. If we  
feel that branches need special controls, we should handle by  
refining our general process. I don't wan't to get hung up fixing  
*everything*...

Any other comments?

More inline...

On Sep 6, 2006, at 7:27 PM, Jason Dillon wrote:

> Thanks Kevan for the summary, I think this really helps.
>
> More comments below inline...
>
> On Sep 6, 2006, at 1:34 PM, Kevan Miller wrote:
>> 1. Relaxed RTC
>>
>> ...
>>
>> * 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.
>
> I don't think that we need a requirement of a PMC vote here.  The  
> PMC can provide enough oversight w/o a required vote.  IMO, a vote  
> is a vote is a vote... I don't put any weight over a committers  
> vote to a PMC members vote.  I value them both equally.  Forcing a  
> PMC vote here is artificial and promotes separatism rather than unity.

Totally agree. I almost made that change, but was consciously trying  
*not* to edit the proposals as I pulled them out of the various  
discussion threads.

>
>
>> 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.
>
> For the most part I like this model... but only for non-trivial  
> changes, see below.

It's not bad and I think we can operate quite reasonably using this.  
However, I don't think it's necessary. I'd prefer to see the benefits  
of this approach handled by more up-front communication using CTR. By  
the time something is committed, it's not much of a surprise...

>
>
>> 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.
>
> This feels a whole lot like common-sense for how to participate on  
> an open-source project.  In most cases, I think this is also the  
> best model to run under... though I do believe that RTC has some  
> merit as well.
>
> If it was up to me (which it isn't, but here is my opinion  
> anyways), I would use a hybrid model, which would default to CTR  
> (with emphasis on common sense and communication) and for non- 
> trivial or potentially controversial changes follow the RTC with  
> Lazy Consensus as described in #2 (with the addition of inclusion  
> of development branches or patches, depending on the complexity).   
> I actually think that this is common-sense too.
>
> IMO... this is the best of both worlds, without being too  
> overbearing on policy and process, leveraging the trust of the  
> developers and fostering our community with sufficient oversight  
> and freedom to allow real progress to be achieved.

I think RTC w/ lazy consensus is always available under a CTR model.  
However, I'd prefer it be self-imposed rather than expected. I  
wouldn't be upset if someone didn't follow RTC for a significant  
change. I would be upset if they failed to adequately communicate and  
discuss with the community...

>
>  * * *
>
> But Jason... how do I know what is non-trivial or controversial?

Jason, Perhaps it's time for a little holiday...  ;-)

--kevan

Mime
View raw message