On Tue, Feb 7, 2017 at 10:18 AM, Francesco Romani <fromani@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@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@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)