geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [SUMMARY] Proposed Geronimo Development Processes
Date Sat, 09 Sep 2006 20:41:54 GMT
I think the overwhelming need is that more than the author  
understands and agrees with the main thrust of a major change.  I  
think that the apply-and-test RTC requirement we've been struggling  
under has severely inhibited thorough review, but that's just my  
experience.

I'm in favor of (3) for trunk and (2) for bug-fix branches and also  
in favor of reviewing this change in a month or two to see if we are  
actually reviewing changes sufficiently and in a sufficiently timely  
manner.

thanks
david jencks



On Sep 7, 2006, at 12:59 PM, Kevan Miller wrote:

> 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