One of these patchsets was mine, so I feel qualified to send a response :)
On 04/04/2016 12:06 PM, Armando M. wrote:
On 4 April 2016 at 09:51, Ihar Hrachyshka <ihrac...@redhat.com
<mailto:ihrac...@redhat.com>> wrote:
Doug Wiegley <doug...@parksidesoftware.com
<mailto:doug...@parksidesoftware.com>> wrote:
On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka
<ihrac...@redhat.com <mailto:ihrac...@redhat.com>> wrote:
Armando M. <arma...@gmail.com <mailto:arma...@gmail.com>>
wrote:
On 4 April 2016 at 09:01, Ihar Hrachyshka
<ihrac...@redhat.com <mailto:ihrac...@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.
Emails don't work. Or work just occasionally.
Openstack Dev mailing list is pretty crowded, so sometimes to read
everything, takes hours. In this situation, important message can be
easily skipped.
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 :)
I'll shortly describe the situation.
My patchset got approved. It had +W and gate pre-approved it, but failed
on final merge. So at the end landed as +2, +W and -2 from gate.
I didn't know what happened until I've seen Armando's "-2" with
explanation. Even though I'm trying to be proactive on IRC channel about
possible gate problems.
So it's definitely good method to "be aware". But, in the same time it
was very strange to me. I had everything prepared to be merged, but it
didn't got merge.
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.
I don't think "-1" would work in case described by me.
Patchset was already approved, and would still land in queue.
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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
