<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 4 April 2016 at 09:51, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Doug Wiegley <<a href="mailto:dougwig@parksidesoftware.com" target="_blank">dougwig@parksidesoftware.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>> wrote:<br>
<br>
Armando M. <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 4 April 2016 at 09:01, Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>> wrote:<br>
Hi all,<br>
<br>
I noticed that often times we go and -2 all the patches in the review queue on every neutron specific gate breakage spotted. This is allegedly done to make sure that nothing known to be broken land in merge gate until we fix the breakage on our side.<br>
<br>
This is not allegedly done. When I do it, I put a comment next to my action.<br>
<br>
<br>
<br>
While I share the goal of not resetting the gate if we can avoid it, I find the way we do it a bit too aggressive. Especially considering that often times those -2 votes sit there not cleared even days after the causing breakage is fixed, needlessly blocking patches landing.<br>
<br>
That's a blatant lie: I am aggressive at putting -2s as well as removing them. Other changes for those the -2 stick is probably because they aren't worth the hassle. We've been also in feature freeze so slowing things down should have hurt anyway.<br>
<br>
<br>
I suggest we either make sure that we remove those -2 votes right after gate fixes land, or we use other means to communicate to core reviewers that there is a time window when nothing should land in the merge queue.<br>
<br>
Initially I tried sending emails ahead of time alerting for gate breakages, but that doesn't work for obvious reasons: there is a lag that can still be fatal.<br>
<br>
On the specific circumstance, gate broke on Friday late afternoon PDT. It didn't seem that was anything critical worth merging at all cost that couldn't wait until Monday morning and I didn't bother check that things merged safely in the middle of my weekend.<br>
</blockquote>
<br>
Yeah, but it’s already up to two working days in some places.<br>
</blockquote>
<br>
Not that -2’s sitting around is good, but what is so urgent that two days affects the overall flow of things, and didn’t get escalated?  Review chains can address collaboration issues.  Monster syntax churns with lots of conflicts get more annoying, but they’re annoying for everyone anyway. The worst part of two days with a -2 is the fact that no one will look at it and give feedback during that time period, IMO, not that it takes longer to merge.  Velocity is about throughput, not latency.<br>
</blockquote>
<br></span>
It is definitely not the end of the world. The process of -2 cancellation is just non-transparent, and I am not sure whether I need to reach the vote owner to remove it, or it will just magically vanish. I had inconsistent experiences with freezing -2’s in OpenStack.<br></blockquote><div><br></div><div>If the vote doesn't magically vanish when you expect to, you can simply reach out the person. When has that become a problem, especially when that person is usually available on irc and generally very responsive?</div><div><br></div><div><div>The -2 keeps you on your toes and aware of the state of the gate, which to me is a good thing :)</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Landing a patch earlier lowers the chance of git conflict for other patches being crafted in parallel with it; it also removes the need for a core reviewer to get back to it and +W later, in case enough +2 votes are there. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I like the idea of adopting -1 instead of -2 and looking whether it still works for the initial goal of avoiding gate resets.<br>
<br>
btw does anyone know whether other projects apply a similar cautious approach when dealing with their gate breakages?<div class=""><div class="h5"><span style="color:rgb(34,34,34)"> </span><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
<br>
Ihar<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>