On 4 April 2016 at 09:51, Ihar Hrachyshka <[email protected]> wrote:
> Doug Wiegley <[email protected]> wrote: > > On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka <[email protected]> wrote: >>> >>> Armando M. <[email protected]> wrote: >>> >>> On 4 April 2016 at 09:01, Ihar Hrachyshka <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
