Automation moving bug to modified when it is not

[Michal Skrivanek]

> 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

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
> irc: eedri (on #tlv #rhev-dev #rhev-integ)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160719/d95428ed/attachment.html>