On 13 November 2017 at 11:10, Allon Mureinik <amureini@redhat.com> wrote:
> Commit 86bf82e746404145e8b97df46f514086e4f82e69 is probably the offending
> commit, taking a deeper look now, should have a fix within the hour
>

Hmm, I see what happened there, that commit is
https://gerrit.ovirt.org/c/83920, so it was tested at:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3769
and passed.

BUT, it was tested along with https://gerrit.ovirt.org/#/c/83918/2
that was merged earlier as far as git ordering goes, but somehow was
assumed to be a later patch. When we test multiple patches from the
same project we essentially use packages built from the one we deem to
be the latest. So in this case only the packages from 83918 were
actually tested.

We went to great lengths to preserve correct patch ordering by
preserving the order of event notifications reaching us from gerrit.
But here it seems we ended out with out-of-order patches. Do you have
any idea how did we end up with this? Do you remember what was the
sequence in which you clicked the 'merge' button on the different
patches?

--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted