[openstack-dev] [neutron] -2'ing all patches on every gate breakage

Ihar Hrachyshka ihrachys at redhat.com
Mon Apr 4 16:51:25 UTC 2016

Doug Wiegley <dougwig at parksidesoftware.com> wrote:

>> On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>> Armando M. <armamig at gmail.com> wrote:
>>> On 4 April 2016 at 09:01, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>>> Hi all,
>>> 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.
>>> This is not allegedly done. When I do it, I put a comment next to my  
>>> action.
>>> 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.
>>> 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.
>>> 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.
>>> 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.
>>> 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.
>> Yeah, but it’s already up to two working days in some places.
> 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.

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.

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.

I like the idea of adopting -1 instead of -2 and looking whether it still  
works for the initial goal of avoiding gate resets.

btw does anyone know whether other projects apply a similar cautious  
approach when dealing with their gate breakages?


More information about the OpenStack-dev mailing list