Automation moving bug to modified when it is not

[Eyal Edri]

On Tue, Jul 19, 2016 at 4:33 PM, Michal Skrivanek <mskrivan at redhat.com>
wrote:

>
> On 19 Jul 2016, at 14:25, Eyal Edri <eedri at redhat.com> wrote:
>
>
>
> On Tue, Jul 19, 2016 at 1:37 PM, Michal Skrivanek <mskrivan at redhat.com>
> wrote:
>
>>
>> On 19 Jul 2016, at 12:15, Eyal Edri <eedri at redhat.com> wrote:
>>
>> This happened because you used the same bug for master and 4.0.
>>
>>
>> right, but that’s the regular state of things because upstream there is
>> no separate bug for master vs current version
>>
>> The Gerrit hook doesn't verify status between major versions, only inside
>> a single version (for e.g, it would not move to modified if you needed to
>> backport to 4.0.1 and the target milestone was 4.0.1).
>> I'm not sure how we can tackle this, because master has no meaning in
>> bugzilla, it doesn't correlate to a version.
>>
>> One think I can think of, is NOT to move bugs to MODIFIED is a patch was
>> merged on master branch... , will that help?
>>
>>
>> I’m not sure if it’s better because before 4.1 is branched the master
>> development is for 4.1 bugs.
>> It would make sense to differentiate based on whether a branch for that
>> TM version exists or not, so in your above example since the bug has TM
>> 4.0.x and there is a 4.0 branch it would wait for a backport
>>
>
> I can't compare it to 4.0 because master is a moving target, so this hook
> will misbehave once master change versions, I need a solid logic that will
> work all the time for bugs on master.
> either not move them to MODIFIED if the bug is on target milestone !=
> master (which is probably 100% of the times) or some regex we can use... I
> don't have any other creative ideas…
>
>
> I guess if we have TM as x.y.z and the projects have x.y branch we can
> check for that, right? if the branch is not there then master is the final
> branch; if TM x.y.z matches some ovirt-x.y branch the backport is needed.
>

We already do that, that's why if you have branch 4.0.1 and you merge a
patch to ovirt-engine, but I think master was left out of this logic, since
it didn't have -x.y.z suffix.
I think this [1] should solve it, please review.

[1] https://gerrit.ovirt.org/#/c/61073/1


>
> You can look at the code if you want at [1] and see if you have an idea.
>
> [1]
> https://gerrit.ovirt.org/gitweb?p=gerrit-admin.git;a=blob;f=hooks/custom_hooks/change-merged.set_MODIFIED;h=678806dc35a372dadab5a5a392d25409db5c8275;hb=refs/heads/master
>
>
>>
>> Thanks,
>> michal
>>
>>
>>
>> On Tue, Jul 19, 2016 at 8:07 AM, Michal Skrivanek <mskrivan at redhat.com>
>> wrote:
>>
>>> Example in bug https://bugzilla.redhat.com/show_bug.cgi?id=1357440
>>> It doesn't take into account branches
>>>
>>> Thanks,
>>> michal
>>>
>>
>>
>>
>> --
>> Eyal Edri
>> Associate Manager
>> RHEV DevOps
>> EMEA ENG Virtualization R&D
>> Red Hat Israel
>>
>> phone: +972-9-7692018
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>
>>
>>
>
>
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
>
>


-- 
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160720/dcc3292b/attachment.html>