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

Reply via email to