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 <nik...@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.math...@gmail.com>wrote: > >> >> On Fri, Oct 11, 2013 at 1:34 PM, Clint Byrum <cl...@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> >> -Dolph >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@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: konglingx...@huawei.com; anlin.k...@gmail.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
