On 04/04/2016 11:41 AM, Armando M. wrote:
On 4 April 2016 at 09:36, Ihar Hrachyshka <[email protected]
<mailto:[email protected]>> wrote:
Graham <[email protected] <mailto:[email protected]>> wrote:
On 04/04/2016 17:11, Ihar Hrachyshka 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.
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.
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.
Thanks,
Ihar
I recently submitted https://review.openstack.org/295253 as an
idea for
designate to prioritize reviews.
Something similar could be a good solution, in conjunction
with a bot.
So, when a gate breakage starts, saying "!gate breakage" would
apply a
"-1 Procedural Block" that gets removed when "!gate fixed" was
said?
This removes the need for humans to do the removal (and try and
remember which reviews were really -2'd or they had had a -1 on)
Thanks for the idea, that’s indeed an interesting approach. It
also helps in that now any core member would be able to
consistently block project patches for merge gate, or cancel the
alert.
Armando, do you think we could try to adopt the approach? If yes,
I may look into a patch for that.
Um, not sure, it feels over-engineered.
My $0.02
Recently, we had several gate breakages, so it would be nice to have
automatic tool to block/unblock patchsets without any problem.
I don't know if this is a good solution, but could give *power* to all
core reviewers to immediately give "STOP" sign for all patchsets.
--
Darek
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
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