10:19 a.m.
--Apple-Mail=_745D14C7-E31B-46BD-9AD9-F1992E0F2C73
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 18 Aug 2016, at 09:09, Sandro Bonazzola
<sbonazzo(a)redhat.com> =
wrote:
=20
=20
=20
On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com =
<mailto:nsoffer@redhat.com>> wrote:
On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com =
<mailto:eedri@redhat.com>> wrote:
>
>
> On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com =
<mailto:nsoffer@redhat.com>> wrote:
>>
>> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com =
<mailto:eedri@redhat.com>> wrote:
>> > I still thinks its a very valuable hook and we are
aware of the =
fact it
>> > has
>> > bugs, especially with patches on master branch and 4.0.
>> >
>> > Shlomi from the infra team is working on a solution for it as we =
speak
>> > and
>> > we hope to have a solution in the next few days, however it's =
not
>> > trival to
>> > test and requires setting up a staging env and improve loga for =
the
>> > hooks
>> > system.
>>
>> How do you plan to solve this?
>>
>> Only the owner of the bug knows if the all the required patches are =
merged
>
>
> The authors should use Bug-Url on the main bug and related-to: on =
other
> patches that are related.
=20
This is not possible. Many times you need series of patches to fix a =
bug, and
you the number of patches may change during development. You start =
with one
patch, and later you find that you need another one, so all of them =
will have
a bug url.
=20
Practically, you should expect that all patches in the series will
have a bug-url.
If the hook will change the bug incorrectly someone will have to fix =
this, and
it is very unlikely that a developer will go to clean after the
hook.
=20
>> and backported to the correct repositories.
>
>
> This is done with logic according to the bug target milestone.
>
> for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug =
targeted to
> ovirt-4.0.2.
> The hook should check if branch 4.0.2 exists or not, if it exists =
then the
> bug should NOT move to MODIFIED,
> since it needs still backporting to ovirt-engine-4.0.2 branch.
=20
This is too fragile. For example, maybe a 4.0.2 branch is created =
after
the patch was merged to 4.0 branch, and the patch will be missing, =
although
the bug is already set to modified.
=20
Setting to modified should be done by the owner of the bug, after =
verifying
that the patches exists in correct branch.
=20
I'm not suggesting to remove the hook, just disable the feature of =
making
a bug modified.
=20
+1. On build day checking that bugs in modified not listed in Bug-Url =
on the
build branch due to missing backport is a painful experience.
it is a tradeoff. It was mentioned before that the other way around we =
would be left with too many POSTed bugs which are actually already =
merged. The maintainer is typically not the assignee so if you e.g. =
merge the last patch on Thursday afternoon it takes some time to gets =
attention, in the meantime there is a build which won=E2=80=99t consider =
that bug.
=20
=20
=20
Nir
=20
=20
=20
--=20
Sandro Bonazzola
Better technology. Faster innovation. Powered by community =
collaboration.
See how it works at redhat.com <http://redhat.com/>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--Apple-Mail=_745D14C7-E31B-46BD-9AD9-F1992E0F2C73
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote
type=3D"cite" class=3D""><div =
class=3D"">On 18 Aug 2016, at 09:09, Sandro Bonazzola <<a =
href=3D"mailto:sbonazzo@redhat.com"
class=3D"">sbonazzo(a)redhat.com</a>&gt;=
wrote:</div><br class=3D"Apple-interchange-newline"><div
class=3D""><div =
dir=3D"ltr" class=3D""><br class=3D""><div
class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Wed, Aug 17, 2016 at
5:12 PM, =
Nir Soffer <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:nsoffer@redhat.com" target=3D"_blank" =
class=3D"">nsoffer(a)redhat.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=3D"">On =
Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <<a =
href=3D"mailto:eedri@redhat.com"
class=3D"">eedri(a)redhat.com</a>&gt; =
wrote:<br class=3D"">
><br class=3D"">
><br class=3D"">
> On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <<a =
href=3D"mailto:nsoffer@redhat.com"
class=3D"">nsoffer(a)redhat.com</a>&gt; =
wrote:<br class=3D"">
>><br class=3D"">
</span><span class=3D"">>> On Wed, Aug 17, 2016 at
1:45 PM, Eyal =
Edri <<a href=3D"mailto:eedri@redhat.com" =
class=3D"">eedri(a)redhat.com</a>&gt; wrote:<br
class=3D"">
>> > I still thinks its a very valuable hook and we are aware =
of the fact it<br class=3D"">
>> > has<br class=3D"">
>> > bugs, especially with patches on master branch and =
4.0.<br class=3D"">
>> ><br class=3D"">
>> > Shlomi from the infra team is working on a solution for it =
as we speak<br class=3D"">
>> > and<br class=3D"">
>> > we hope to have a solution in the next few days, =
however it's not<br class=3D"">
>> > trival to<br class=3D"">
>> > test and requires setting up a staging env and improve =
loga for the<br class=3D"">
>> > hooks<br class=3D"">
>> > system.<br class=3D"">
>><br class=3D"">
>> How do you plan to solve this?<br class=3D"">
>><br class=3D"">
</span><span class=3D"">>> Only the owner of the bug
knows if the =
all the required patches are merged<br class=3D"">
><br class=3D"">
><br class=3D"">
</span><span class=3D"">> The authors should use Bug-Url on
the main =
bug and related-to: on other<br class=3D"">
> patches that are related.<br class=3D"">
<br class=3D"">
</span>This is not possible. Many times you need series of patches to =
fix a bug, and<br class=3D"">
you the number of patches may change during development. You start with =
one<br class=3D"">
patch, and later you find that you need another one, so all of them will =
have<br class=3D"">
a bug url.<br class=3D"">
<br class=3D"">
Practically, you should expect that all patches in the series will<br =
class=3D"">
have a bug-url.<br class=3D"">
If the hook will change the bug incorrectly someone will have to fix =
this, and<br class=3D"">
it is very unlikely that a developer will go to clean after the hook.<br =
class=3D"">
<span class=3D""><br class=3D"">
>> and backported to the correct repositories.<br
class=3D"">
><br class=3D"">
><br class=3D"">
</span><span class=3D"">> This is done with logic according
to the =
bug target milestone.<br class=3D"">
><br class=3D"">
> for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug =
targeted to<br class=3D"">
> ovirt-4.0.2.<br class=3D"">
> The hook should check if branch 4.0.2 exists or not, if it exists =
then the<br class=3D"">
> bug should NOT move to MODIFIED,<br class=3D"">
> since it needs still backporting to ovirt-engine-4.0.2 branch.<br =
class=3D"">
<br class=3D"">
</span>This is too fragile. For example, maybe a 4.0.2 branch is created =
after<br class=3D"">
the patch was merged to 4.0 branch, and the patch will be missing, =
although<br class=3D"">
the bug is already set to modified.<br class=3D"">
<br class=3D"">
Setting to modified should be done by the owner of the bug, after =
verifying<br class=3D"">
that the patches exists in correct branch.<br class=3D"">
<br class=3D"">
I'm not suggesting to remove the hook, just disable the feature of =
making<br class=3D"">
a bug modified.<br class=3D""></blockquote><div
class=3D""><br =
class=3D""></div><div class=3D"">+1. On build day
checking that bugs in =
modified not listed in Bug-Url on the build branch due to missing =
backport is a painful =
experience.</div></div></div></div></div></blockquote><div><br
=
class=3D""></div>it is a tradeoff. It was mentioned before that the =
other way around we would be left with too many POSTed bugs which are =
actually already merged. The maintainer is typically not the assignee so =
if you e.g. merge the last patch on Thursday afternoon it takes some =
time to gets attention, in the meantime there is a build which won=E2=80=99=
t consider that bug.</div><div><br
class=3D""></div><div><br =
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div
class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D""><br
class=3D""></div><div =
class=3D""> </div><blockquote
class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"
class=3D""><br class=3D"">
Nir<br class=3D"">
</font></span></blockquote></div><br
class=3D""><br clear=3D"all" =
class=3D""><div class=3D""><br
class=3D""></div>-- <br class=3D""><div =
class=3D"gmail_signature"
data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr" class=3D""><div class=3D""><div
dir=3D"ltr" class=3D"">Sandro =
Bonazzola<br class=3D"">Better technology. Faster innovation. Powered by
=
community collaboration.<br class=3D"">See how it works at <a =
href=3D"http://redhat.com/" target=3D"_blank"
class=3D"">redhat.com</a><br=
class=3D""></div></div></div></div>
</div></div>
_______________________________________________<br class=3D"">Devel =
mailing list<br class=3D""><a href=3D"mailto:Devel@ovirt.org"
=
class=3D"">Devel(a)ovirt.org</a><br =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<...
</div><br class=3D""></body></html>=
--Apple-Mail=_745D14C7-E31B-46BD-9AD9-F1992E0F2C73--