geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Returning to Commit-Then-Review?
Date Mon, 28 Aug 2006 05:51:11 GMT
I guess... though I'm still not really sure that we need to be this  
formal about things.

For example, ActiveMQ seems to be working fine with CTR, and they are  
getting releases out quickly and features implemented.  Seems like we  
are getting so bogged down by politics :-(

But I do think that it is natural and rather obvious that if  
something big is going to change that there should be discussion  
about it on the list... so that everyone is on the same page.

--jason


On Aug 25, 2006, at 3:17 PM, Dain Sundstrom wrote:

> I think you analysis is spot on. The only think I would change is  
> the "how" section at the top.  I'd rather see that to commit you  
> need either 3 +1 (no -1s) from a committer or 72 hours pass which  
> ever happens first unless there is active discussion.  Also, I'd  
> strongly suggest one complains loudly if they get no comments after  
> 48 hours.
>
> -dain
>
> On Aug 25, 2006, at 1:47 PM, David Blevins wrote:
>
>> So anyone have any thoughts on this?  I'll assume there's no  
>> support unless I hear otherwise.
>>
>> -David
>>
>> On Aug 23, 2006, at 1:14 PM, David Blevins wrote:
>>
>>> On Aug 22, 2006, at 6:56 PM, David Blevins wrote:
>>>
>>>> I'd be more inclined to talk about what we want to apply it to  
>>>> and how.
>>>
>>> More thoughts on the "where" and "how" topic.
>>>
>>> So far my thoughts on "how"; review to your satisfaction and +1,  
>>> 72 hour cut off.
>>>
>>> As far as "where" ....
>>>
>>> I'm inclined to say "at your discretion" where the following are  
>>> encouraged:
>>>  - Significant new functionality
>>>  - Significant changes
>>>  - Patches from Contributors
>>>  - Borderline "fixes" to a stable branch
>>>
>>> Whether or not it merits RTC would be at your discretion.  It is to
>>> your advantage in these situations because:
>>>
>>> - "Significant new functionality" and "Significant changes": It's a
>>>    "Get out of jail free" card.  Having more people understand your
>>>    code keeps you from spending all day on the user list.  You do
>>>    support your code on the user list, right?
>>>
>>> - "Patches from Contributors": Getting three votes for your patches
>>>    is not a bad way to, in time, get your three votes to be a
>>>    committer.  Let's be clear, someone who commits all your patches
>>>    with no review from others on the project isn't doing you any
>>>    favors.  It's in your interest to push to get your votes on every
>>>    patch.
>>>
>>> - "Borderline 'fixes' to a stable branch": It's a given you will
>>>    think everything you want to put in a stable branch is important.
>>>    But, is it a fix or is it a new feature?  If you think others may
>>>    disagree, you may want to put it up for review or you may find
>>>    yourself running the TCK all alone with no help.
>>>
>>>
>>> Those are the advantages you stand to gain should you choose to  
>>> use RTC for any of the above situations.  RTC is not the only way  
>>> to get the above benefits, so it is at your discretion whether or  
>>> not your situation merits it.
>>>
>>> My pragmatic take on RTC for the moment.
>>>
>>> -David
>>>
>


Mime
View raw message