Open Stack

On 4 April 2016 at 09:51, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> 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.
>

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?

The -2 keeps you on your toes and aware of the state of the gate, which to
me is a good thing :)


>
> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160404/ff1f9a40/attachment.html>