On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo@redhat.com> = wrote: =20 =20 =20 On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer@redhat.com = <mailto:nsoffer@redhat.com>> wrote: On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri@redhat.com = <mailto:eedri@redhat.com>> wrote:
On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer@redhat.com =
<mailto:nsoffer@redhat.com>> wrote:
On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri@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 =
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 =
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 =
--Apple-Mail=_745D14C7-E31B-46BD-9AD9-F1992E0F2C73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 the this, and 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@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@redhat.com</a>>= 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@redhat.com</a>></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@redhat.com</a>> = 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@redhat.com</a>> = 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@redhat.com</a>> 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@ovirt.org</a><br = class=3D"">http://lists.ovirt.org/mailman/listinfo/devel</div></blockquote=
</div><br class=3D""></body></html>=
--Apple-Mail=_745D14C7-E31B-46BD-9AD9-F1992E0F2C73--