Check out this patches for instance: https://gerrit.ovirt.org/#/c/68862 https://gerrit.ovirt.org/#/c/68861 Those are 4.1 and 4.0 patches that are open on master, I'd expect to see them get -verified from the hooks which they didn't: - Update Tracker::#1406042::OK, status: POST - Check Bug-Url::OK - Check Product::#1406042::OK, product: ovirt-engine - Check TM::#1406042::OK, found clone candidate ovirt-4.0.zfor target milestone: ovirt-4.0.7 - Set POST::#1406042::IGNORE, bug is already in 'POST' status - Check Backport::IGNORE, The patch backported to all newer branches.(open in 'master' branch/es) found not relevant branch/es: 'ovirt-engine-4.0' (not exist in the newer branches list) This was the flow before and it made my life easier as I didn't have to actively search for cherry-picks in all other branches to see if it can be merged _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

The hook found out that the patch is open in master which precedes ovirt-engine-4.1 and thus should have gotten -verified in 4.1 On Wed, Dec 21, 2016 at 12:55 PM, Shlomo Ben David <sbendavi(a)redhat.com&gt; wrote: > Hi Tal, > > I think that the Check Backport hook is doing exactly what you asking for. > Example [1]: > > - Check Backport::IGNORE, The patch backported to all newer > branches.(open in 'master' branch/es) found not relevant branch/es: > 'ovirt-engine-4.0' (not exist in the newer branches list) > > patch branch: ovirt-engine-4.1 > newer branches: 'master' (open) > older (not relevant) branches: ovirt-engine-4.0 > > If it's not what you meant, please explain :) > > [1] - https://gerrit.ovirt.org/#/c/68862 > > > Best Regards, > > Shlomi Ben-David | Software Engineer | Red Hat ISRAEL > RHCSA | RHCE > IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) > > OPEN SOURCE - 1 4 011 && 011 4 1 > > On Wed, Dec 21, 2016 at 12:39 PM, Tal Nisan <tnisan(a)redhat.com&gt; wrote: > >> Check out this patches for instance: https://gerrit.ovirt.org/#/c/68862 >> https://gerrit.ovirt.org/#/c/68861 >> Those are 4.1 and 4.0 patches that are open on master, I'd expect to see >> them get -verified from the hooks which they didn't: >> >> - Update Tracker::#1406042::OK, status: POST >> - Check Bug-Url::OK >> - Check Product::#1406042::OK, product: ovirt-engine >> - Check TM::#1406042::OK, found clone candidate ovirt-4.0.zfor >> target milestone: ovirt-4.0.7 >> - Set POST::#1406042::IGNORE, bug is already in 'POST' status >> - Check Backport::IGNORE, The patch backported to all newer >> branches.(open in 'master' branch/es) found not relevant branch/es: >> 'ovirt-engine-4.0' (not exist in the newer branches list) >> >> This was the flow before and it made my life easier as I didn't have to >> actively search for cherry-picks in all other branches to see if it can be >> merged >> >> _______________________________________________ >> Infra mailing list >> Infra(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra >> >> >

This is how it always worked, and all due respect to Eyal's opinion I'm the one handling the branch and the grades are there to help me :)

On Wed, Dec 21, 2016 at 1:32 PM, Shlomo Ben David <sbendavi(a)redhat.com&gt; wrote: > Tal - Ok, so basically I didn't apply the verified grades on any hooks > accept the check_bug_url hook. > > Eyal - Is it ok to add the verify (+/-)1 grade for the check_backport > hook? > (I thought that we'll grade with negative value if something went wrong) > > Best Regards, > > Shlomi Ben-David | Software Engineer | Red Hat ISRAEL > RHCSA | RHCE > IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) > > OPEN SOURCE - 1 4 011 && 011 4 1 > > On Wed, Dec 21, 2016 at 1:20 PM, Tal Nisan <tnisan(a)redhat.com&gt; wrote: > >> The hook found out that the patch is open in master which precedes >> ovirt-engine-4.1 and thus should have gotten -verified in 4.1 >> >> On Wed, Dec 21, 2016 at 12:55 PM, Shlomo Ben David <sbendavi(a)redhat.com&gt; >> wrote: >> >>> Hi Tal, >>> >>> I think that the Check Backport hook is doing exactly what you asking >>> for. >>> Example [1]: >>> >>> - Check Backport::IGNORE, The patch backported to all newer >>> branches.(open in 'master' branch/es) found not relevant branch/es: >>> 'ovirt-engine-4.0' (not exist in the newer branches list) >>> >>> patch branch: ovirt-engine-4.1 >>> newer branches: 'master' (open) >>> older (not relevant) branches: ovirt-engine-4.0 >>> >>> If it's not what you meant, please explain :) >>> >>> [1] - https://gerrit.ovirt.org/#/c/68862 >>> >>> >>> Best Regards, >>> >>> Shlomi Ben-David | Software Engineer | Red Hat ISRAEL >>> RHCSA | RHCE >>> IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) >>> >>> OPEN SOURCE - 1 4 011 && 011 4 1 >>> >>> On Wed, Dec 21, 2016 at 12:39 PM, Tal Nisan <tnisan(a)redhat.com&gt; wrote: >>> >>>> Check out this patches for instance: https://gerrit.ovirt >>>> .org/#/c/68862 https://gerrit.ovirt.org/#/c/68861 >>>> Those are 4.1 and 4.0 patches that are open on master, I'd expect to >>>> see them get -verified from the hooks which they didn't: >>>> >>>> - Update Tracker::#1406042::OK, status: POST >>>> - Check Bug-Url::OK >>>> - Check Product::#1406042::OK, product: ovirt-engine >>>> - Check TM::#1406042::OK, found clone candidate ovirt-4.0.zfor >>>> target milestone: ovirt-4.0.7 >>>> - Set POST::#1406042::IGNORE, bug is already in 'POST' status >>>> - Check Backport::IGNORE, The patch backported to all newer >>>> branches.(open in 'master' branch/es) found not relevant branch/es: >>>> 'ovirt-engine-4.0' (not exist in the newer branches list) >>>> >>>> This was the flow before and it made my life easier as I didn't have >>>> to actively search for cherry-picks in all other branches to see if it can >>>> be merged >>>> >>>> _______________________________________________ >>>> Infra mailing list >>>> Infra(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/infra >>>> >>>> >>> >> >

OK great, in any way I'm there to solve any false positives as I can remove those votes and as you see I notify you team immediately of any failure so should be a problem On Wed, Dec 21, 2016 at 1:40 PM, Eyal Edri <eedri(a)redhat.com&gt; wrote: > > > On Wed, Dec 21, 2016 at 1:35 PM, Tal Nisan <tnisan(a)redhat.com&gt; wrote: > >> This is how it always worked, and all due respect to Eyal's opinion I'm >> the one handling the branch and the grades are there to help me :) >> > > The reason we didn't grade the new hooks with CR -1 or VERIFY -1 is > because we wanted to give the new hooks enough time to see if all is > working well, because causing false positives and un-needed noise, > nothing to do with my opinions. > > Since we see now that its working well, we can enable the enforcement > back, so if its VERIFY then yea, let's enable it. > > >> >> On Wed, Dec 21, 2016 at 1:32 PM, Shlomo Ben David <sbendavi(a)redhat.com&gt; >> wrote: >> >>> Tal - Ok, so basically I didn't apply the verified grades on any hooks >>> accept the check_bug_url hook. >>> >>> Eyal - Is it ok to add the verify (+/-)1 grade for the check_backport >>> hook? >>> (I thought that we'll grade with negative value if something went wrong) >>> >>> Best Regards, >>> >>> Shlomi Ben-David | Software Engineer | Red Hat ISRAEL >>> RHCSA | RHCE >>> IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) >>> >>> OPEN SOURCE - 1 4 011 && 011 4 1 >>> >>> On Wed, Dec 21, 2016 at 1:20 PM, Tal Nisan <tnisan(a)redhat.com&gt; wrote: >>> >>>> The hook found out that the patch is open in master which precedes >>>> ovirt-engine-4.1 and thus should have gotten -verified in 4.1 >>>> >>>> On Wed, Dec 21, 2016 at 12:55 PM, Shlomo Ben David < >>>> sbendavi(a)redhat.com&gt; wrote: >>>> >>>>> Hi Tal, >>>>> >>>>> I think that the Check Backport hook is doing exactly what you asking >>>>> for. >>>>> Example [1]: >>>>> >>>>> - Check Backport::IGNORE, The patch backported to all newer >>>>> branches.(open in 'master' branch/es) found not relevant branch/es: >>>>> 'ovirt-engine-4.0' (not exist in the newer branches list) >>>>> >>>>> patch branch: ovirt-engine-4.1 >>>>> newer branches: 'master' (open) >>>>> older (not relevant) branches: ovirt-engine-4.0 >>>>> >>>>> If it's not what you meant, please explain :) >>>>> >>>>> [1] - https://gerrit.ovirt.org/#/c/68862 >>>>> >>>>> >>>>> Best Regards, >>>>> >>>>> Shlomi Ben-David | Software Engineer | Red Hat ISRAEL >>>>> RHCSA | RHCE >>>>> IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) >>>>> >>>>> OPEN SOURCE - 1 4 011 && 011 4 1 >>>>> >>>>> On Wed, Dec 21, 2016 at 12:39 PM, Tal Nisan <tnisan(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Check out this patches for instance: https://gerrit.ovirt >>>>>> .org/#/c/68862 https://gerrit.ovirt.org/#/c/68861 >>>>>> Those are 4.1 and 4.0 patches that are open on master, I'd expect to >>>>>> see them get -verified from the hooks which they didn't: >>>>>> >>>>>> - Update Tracker::#1406042::OK, status: POST >>>>>> - Check Bug-Url::OK >>>>>> - Check Product::#1406042::OK, product: ovirt-engine >>>>>> - Check TM::#1406042::OK, found clone candidate ovirt-4.0.zfor >>>>>> target milestone: ovirt-4.0.7 >>>>>> - Set POST::#1406042::IGNORE, bug is already in 'POST' status >>>>>> - Check Backport::IGNORE, The patch backported to all newer >>>>>> branches.(open in 'master' branch/es) found not relevant branch/es: >>>>>> 'ovirt-engine-4.0' (not exist in the newer branches list) >>>>>> >>>>>> This was the flow before and it made my life easier as I didn't have >>>>>> to actively search for cherry-picks in all other branches to see if it can >>>>>> be merged >>>>>> >>>>>> _______________________________________________ >>>>>> Infra mailing list >>>>>> Infra(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>>> >>>>>> >>>>> >>>> >>> >> > > > -- > Eyal Edri > Associate Manager > RHV DevOps > EMEA ENG Virtualization R&D > Red Hat Israel > > phone: +972-9-7692018 <+972%209-769-2018> > irc: eedri (on #tlv #rhev-dev #rhev-integ) >