Open Stack

Really a good idea! It's painful for us to summit a patch, then waiting for
reviewing because of the time difference. It's more painful if we get a -1
after getting up. It's very appreciated that if someone could help, and we
can help others, too.


2013/10/12 Nikhil Manchanda <nikhil at manchanda.me>

> Just wanted to chime in that Trove also follows this approach and it's
> worked pretty well for us.
> +1 on Doug's suggestion to leave a comment on the patch so that two
> reviewers don't end up doing the same work fixing it.
>
> Cheers,
> -Nikhil
>
>
>
> On Fri, Oct 11, 2013 at 12:17 PM, Dolph Mathews <dolph.mathews at gmail.com>wrote:
>
>>
>> On Fri, Oct 11, 2013 at 1:34 PM, Clint Byrum <clint at fewbar.com> wrote:
>>
>>> Recently in the TripleO meeting we identified situations where we need
>>> to make it very clear that it is ok to pick up somebody else's patch
>>> and finish it. We are broadly distributed, time-zone-wise, and I know
>>> other teams working on OpenStack projects have the same situation. So
>>> when one of us starts the day and sees an obvious issue with a patch,
>>> we have decided to take action, rather than always -1 and move on. We
>>> clarified for our core reviewers that this does not mean that now both
>>> of you cannot +2. We just need at least one person who hasn't been in
>>> the code to also +2 for an approval*.
>>>
>>> I think all projects can benefit from this model, as it will raise
>>> velocity. It is not perfect for everything, but it is really great when
>>> running up against deadlines or when a patch has a lot of churn and thus
>>> may take a long time to get through the "rebase gauntlet".
>>>
>>> So, all of that said, I want to encourage all OpenStack developers to
>>> say "thanks for fixing my patch" when somebody else does so. It may seem
>>> obvious, but publicly expressing gratitude will make it clear that you
>>> do not take things personally and that we're all working together.
>>>
>>> Thanks for your time -Clint
>>>
>>> * If all core reviewers have been in on the patch, then any two +2's
>>> work.
>>>
>>>
>> +1 across the board -- keystone-core follows this approach, especially
>> around feature freeze / release candidate time.
>>
>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>>
>> -Dolph
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
*--------------------------------------------*
*Lingxian Kong*
Huawei Technologies Co.,LTD.
IT Product Line CloudOS PDU
China, Xi'an
Mobile: +86-18602962792
Email: konglingxian at huawei.com; anlin.kong at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131012/c90cee6b/attachment.html>