<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 4 April 2016 at 09:36, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Graham <<a href="mailto:graham.hayes@hpe.com" target="_blank">graham.hayes@hpe.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/04/2016 17:11, Ihar Hrachyshka wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I noticed that often times we go and -2 all the patches in the review queue<br>
on every neutron specific gate breakage spotted. This is allegedly done to<br>
make sure that nothing known to be broken land in merge gate until we fix<br>
the breakage on our side.<br>
<br>
While I share the goal of not resetting the gate if we can avoid it, I find<br>
the way we do it a bit too aggressive. Especially considering that often<br>
times those -2 votes sit there not cleared even days after the causing<br>
breakage is fixed, needlessly blocking patches landing.<br>
<br>
I suggest we either make sure that we remove those -2 votes right after<br>
gate fixes land, or we use other means to communicate to core reviewers<br>
that there is a time window when nothing should land in the merge queue.<br>
<br>
Thanks,<br>
Ihar<br>
</blockquote>
<br>
I recently submitted <a href="https://review.openstack.org/295253" rel="noreferrer" target="_blank">https://review.openstack.org/295253</a> as an idea for<br>
designate to prioritize reviews.<br>
<br>
Something similar could be a good solution, in conjunction with a bot.<br>
<br>
So, when a gate breakage starts, saying "!gate breakage" would apply a<br>
"-1 Procedural Block" that gets removed when "!gate fixed" was said?<br>
<br>
This removes the need for humans to do the removal (and try and<br>
remember which reviews were really -2'd or they had had a -1 on)<br>
</blockquote>
<br></span>
Thanks for the idea, that’s indeed an interesting approach. It also helps in that now any core member would be able to consistently block project patches for merge gate, or cancel the alert.<br>
<br>
Armando, do you think we could try to adopt the approach? If yes, I may look into a patch for that.</blockquote><div><br></div><div>Um, not sure, it feels over-engineered.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Ihar</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>