[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?
Ihar
More information about the OpenStack-dev
mailing list