On Tue, Nov 17, 2015 at 10:56 AM, Eyal Edri <[email protected]> wrote: > > > On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <[email protected]> > wrote: >> >> On Tue, Nov 17, 2015 at 10:47 AM, David Caro <[email protected]> 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. -- Didi _______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
