<div dir="ltr">Running "git review -d $gerrit_id" will download the patch and create a local branch for you. <div><br></div><div>For example, if I wanted to work on Sandy's patch <a href="https://review.openstack.org/#/c/51249">https://review.openstack.org/#/c/51249</a> I would "git review -d 51249". I can then amend the changeset, rebase, or whatever. Running "git review" will push it up to gerrit again, and as long as I leave the Change-Id in the commit message intact, gerrit will add a new patchset to the existing review.</div>
<div><br></div><div>One small procedural suggestion: Leave a comment on the review to minimize race conditions with other reviewers who are also considering providing fixes.</div><div><div><div><br></div><div><br></div></div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 2:46 PM, David Kranz <span dir="ltr"><<a href="mailto:dkranz@redhat.com" target="_blank">dkranz@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/11/2013 02:34 PM, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Recently in the TripleO meeting we identified situations where we need<br>
to make it very clear that it is ok to pick up somebody else's patch<br>
and finish it. We are broadly distributed, time-zone-wise, and I know<br>
other teams working on OpenStack projects have the same situation. So<br>
when one of us starts the day and sees an obvious issue with a patch,<br>
we have decided to take action, rather than always -1 and move on. We<br>
clarified for our core reviewers that this does not mean that now both<br>
of you cannot +2. We just need at least one person who hasn't been in<br>
the code to also +2 for an approval*.<br>
<br>
I think all projects can benefit from this model, as it will raise<br>
velocity. It is not perfect for everything, but it is really great when<br>
running up against deadlines or when a patch has a lot of churn and thus<br>
may take a long time to get through the "rebase gauntlet".<br>
<br>
So, all of that said, I want to encourage all OpenStack developers to<br>
say "thanks for fixing my patch" when somebody else does so. It may seem<br>
obvious, but publicly expressing gratitude will make it clear that you<br>
do not take things personally and that we're all working together.<br>
<br>
Thanks for your time -Clint<br>
<br>
* If all core reviewers have been in on the patch, then any two +2's<br>
work.<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div></div>
Thanks, Clint. I have wanted to do this in the past but was not sure how. Can you provide the steps to take over some one else's patch and submit it? I volunteer to add it to <a href="https://wiki.openstack.org/wiki/Gerrit_Workflow" target="_blank">https://wiki.openstack.org/<u></u>wiki/Gerrit_Workflow</a>.<span class="HOEnZb"><font color="#888888"><br>

<br>
 -David</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>