automation wrongly moving bugs to MODIFIED

[Yedidyah Bar David]

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.
-- 
Didi