Open Stack

> On Apr 4, 2016, at 10:37 AM, Armando M. <armamig at gmail.com> wrote:
> 
> 
> 
> On 4 April 2016 at 09:22, 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.
> 
> 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.
> 
> I hear ya, but I only blocked 6 patches with one +2, none of which were critical, so I really didn't see much of a disruption; that said, I appreciate your note, and I'll be even more cautious next time.
>  
> 
> Note that I don’t mean you should check anything on your weekend. Instead, I think we should avoid -2’s in this case and teach core reviewers to check some source of gate state truth. An email would actually work as long as everyone actively checks it [if for some reason people are not reading openstack-dev@, let’s To: everyone in the group].
> 
> Perhaps we could try using -1, rather than -2, hoping it gets the same level of attention. Having tried the entire past cycle with emails I don't see how they could work at all.

I don’t know, -1 really means, “there is something wrong, the submitter should fix it and clear the slate.”  Whereas -2 has two meanings.  The first is “procedural block”, and the second is “f*** you.”

I really don’t see a reason not to use the procedural block as a procedural block. Are you not trusting the other cores to remove them or something? It’s literally what it’s there for.

Thanks,
doug



> 
> 
> 
> 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 <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 <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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/ff1812b9/attachment.html>