> On Apr 4, 2016, at 10:37 AM, Armando M. <[email protected]> wrote: > > > > On 4 April 2016 at 09:22, Ihar Hrachyshka <[email protected] > <mailto:[email protected]>> wrote: > Armando M. <[email protected] <mailto:[email protected]>> wrote: > > > > On 4 April 2016 at 09:01, Ihar Hrachyshka <[email protected] > <mailto:[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. > > 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: [email protected]?subject:unsubscribe > <http://[email protected]/?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: [email protected] > <mailto:[email protected]>?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
