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