Open Stack

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 <ihrachys at redhat.com 
> <mailto:ihrachys at redhat.com>> wrote:
>
>     Doug Wiegley <dougwig at parksidesoftware.com
>     <mailto:dougwig at parksidesoftware.com>> wrote:
>
>             On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka
>             <ihrachys at redhat.com <mailto:ihrachys at redhat.com>> wrote:
>
>             Armando M. <armamig at gmail.com <mailto:armamig at gmail.com>>
>             wrote:
>
>                 On 4 April 2016 at 09:01, Ihar Hrachyshka
>                 <ihrachys at redhat.com <mailto: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.
>

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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-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/7c85dd18/attachment.html>