automation at ovirt.org should not change bug to modified when merging into master

Dan Kenigsberg danken at redhat.com
Thu Jul 17 15:37:16 UTC 2014


On Thu, Jul 17, 2014 at 11:19:05AM -0400, Nir Soffer wrote:
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Nir Soffer" <nsoffer at redhat.com>, dcaro at redhat.com
> > Cc: "infra" <infra at ovirt.org>, "Allon Mureinik" <amureini at redhat.com>, "Sean Cohen" <scohen at redhat.com>
> > Sent: Thursday, July 17, 2014 5:54:05 PM
> > Subject: Re: automation at ovirt.org should not change bug to modified when merging into master
> > 
> > On Thu, Jul 17, 2014 at 08:07:28AM -0400, Nir Soffer wrote:
> > > Hi infra,
> > > 
> > > When patch is merged into vdsm master, automation at ovirt.org bot
> > > is updating the bug status to MODIFIED.
> > > 
> > > This behavior is wrong - it should be modified only when merging
> > > into the ovirt-3.5 branch.
> > > 
> > > The current behavior leads to missing fixes in ovirt, and in the next
> > > step, in rhev.
> > > 
> > > Example:
> > > 
> > > 1. http://gerrit.ovirt.org/27122 was merged at Jun 25 3:16 PM
> > > 2. automation at ovirt.org bot changed https://bugzilla.redhat.com/1071654
> > >    to MODIFIED on 2014-06-25 08:16:40 EDT
> > 
> > Strictly speaking, the move to MODIFIED should depend on the target
> > release. After ovirt-3.5 is branched, the bot should track merges to
> > that branch for 3.5.* bugs.
> 
> Right - this issue exists only after new release branch is created.
> I'm not sure how the script can tell this.

At least for Vdsm it's simple: if the target release of the bug is
x.y.z, move to MODIFIED only on merge to the ovirt-x.y branch. If no
such branch exists - a merge to master is enough.



More information about the Infra mailing list