Re: automation wrongly moving bugs to MODIFIED
On Tue, Nov 17, 2015 at 10:56 AM, Eyal Edri <eedri(a)redhat.com> wrote:
On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
>
> On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro(a)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.
--
Didi