Open Stack

On 04/04/2016 11:41 AM, Armando M. wrote:
>
>
> On 4 April 2016 at 09:36, Ihar Hrachyshka <ihrachys at redhat.com 
> <mailto:ihrachys at redhat.com>> wrote:
>
>     Graham <graham.hayes at hpe.com <mailto:graham.hayes at hpe.com>> 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:
>     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/f0a5b6c0/attachment.html>