11:10 a.m.
--Zi0sgQQBxRFxMTsj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 11/17 11:06, Yedidyah Bar David wrote:
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 automatica=
lly
>> >> 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.
=20
Not sure about this. I agree it makes some sense. It definitely don't nee=
d
to
move to modified :-)
=20
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 inc=
lude
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.
--=20
Didi
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
--Zi0sgQQBxRFxMTsj
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWSu76AAoJEEBxx+HSYmnDyiUH/2+tHAOvn1ICB6DMnvm2lqXw
vq33eHwgJ+CcFutnh9q0YVo8heSPM+qdtoaoNmyRrR/QIL4vz1JyZ3m/4PEJBbC4
+LvsTepZAFSg0tBSnBXsATR7SbxG2TB+IoroR3YFktN4NHQOZNP+/KFfRpp/NE51
VA8XE0WAWde1HiV8vfKYqv+s6nB1F9vxmEuKvEiU6ki925ghKiOdJBryomVXjf9H
EDMfPz58SjZTvxEt7bSJsQKrfK2ztj9gMs5tDaKCJ946cllTQWyIyYPgY0vUJMBr
7eAhpjEfCx94ZKP/x2eSZ5RbITVgh2rwnjL98Tb1leKc65HppHq+f0+oP1D1jjU=
=wLH3
-----END PGP SIGNATURE-----
--Zi0sgQQBxRFxMTsj--