Automation moving bug to modified when it is not

Michal Skrivanek mskrivan at redhat.com
Tue Jul 19 13:33:41 UTC 2016


> 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 <mailto:mskrivan at redhat.com>> wrote:
> 
>> On 19 Jul 2016, at 12:15, Eyal Edri <eedri at redhat.com <mailto: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.

> 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 <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 <mailto:mskrivan at redhat.com>> wrote:
>> Example in bug https://bugzilla.redhat.com/show_bug.cgi?id=1357440 <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 <tel:%2B972-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/20160719/bccf8c27/attachment.html>


More information about the Infra mailing list