automation wrongly moving bugs to MODIFIED

[David Caro]

On 11/17 11:06, Yedidyah Bar David wrote:
> On Tue, Nov 17, 2015 at 10:56 AM, Eyal Edri <eedri at redhat.com> wrote:
> >
> >
> > On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi at redhat.com>
> > wrote:
> >>
> >> On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro at redhat.com> wrote:
> >> > On 11/17 10:44, Yedidyah Bar David wrote:
> >> >> See e.g. [1]. Patch was merged to master only (not to 3.6 branch), bug
> >> >> was moved to modified. When I later pushed the patch to 3.6, it
> >> >> correctly moved it back to POST. Not sure we should even automatically
> >> >> move to modified if merged to 3.6, because there might be other
> >> >> changes needed for that bug - it might be best to let the owner to
> >> >> decide.
> >> >
> >> > The issue here is that there's no way for the hooks to know that you
> >> > will be
> >> > pushing more patches, so when it saw that there were no more open
> >> > patches it
> >> > moved the bug to MODIFIED. Is there any reason why you did not open the
> >> > patches
> >> > first?
> >>
> >> There are two different issues here:
> >>
> >> 1. If merging to master branch, and bug is 3.6, bug should not be
> >> moved to modified
> >> at all.
> >
> >
> > imo, the gerrit hook should give -1 on this.
> > either don't put bug-url at all, or put 4.0 bug-url.
> 
> Not sure about this. I agree it makes some sense. It definitely don't need to
> move to modified :-)
> 
> Since we decided to not always clone bugs, and since we require merging to
> master before merging to stable branch, I think it does make sense to include
> the bug-url even in the master patch. obviously, Related-To is also good enough,
> even though a bit misleading - I usually write Related-To when the patch is not
> directly part of a fix for a bug but only related to it.

We used the related-to in the past, but iirc it was dropped as not everyone
used it and people that did, used it for different things.

I still think that opening all the patches before merging any of them is a good
solution.


> -- 
> Didi

-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20151117/4d9b68a5/attachment.sig>