On Tue, Feb 7, 2017 at 10:18 AM, Francesco Romani <fromani(a)redhat.com>
wrote:
On 02/05/2017 12:39 PM, Tal Nisan wrote:
Great, thanks!
I will let you know if something doesn't work as it should
On Sun, Feb 5, 2017 at 12:09 PM, Shlomo Ben David <sbendavi(a)redhat.com>
wrote:
> Hi Tal,
>
> I'm going to apply today the verify grade (-1) for the following hooks:
>
>
> 1. *check_product* - if the patch project is not the same as the bug
> product will return a verify grade (-1).
> 2. *check_target_milestone* - if the patch branch major version is
> not the same as the bug target milestone major version will return a verify
> grade (-1).
>
> Best Regards,
>
>
Let's consider this scenario: we just begin developing the 4.2 version on
the master branch; we just released the 4.1.0 version, so we have the 4.1.z
branch, and we are still supporting the 4.0.z branch.
Let's consider a bug which needs to be backported in the 4.0.z branch,
from master, of course passing throgh 4.1.z
0. bug target milestone is 4.0.N+1 (last release is 4.0.N)
1. patch on master -> OK
2. patch backported first time on branch 4.1.z
-> check_target_milestone fails! branch major 4.1, bug target 4.0
It seems that this flow doesn't cover the case on which we need a double
backport.
We are aware of that option, i.e "clone candidate" bugs, and if we see that
the bug has 2 version flags ( e.g ovirt-4.1 + ovirt-4.0 ) then it shouldn't
give -1.
If it still fails on bugs that are 'clone candidate' then its a bug and we
should fix it.
Bests,
--
Francesco Romani
Red Hat Engineering Virtualization R & D
IRC: fromani
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)