On 18 Aug 2016, at 09:32, Sandro Bonazzola <sbonazzo@redhat.com> = wrote: =20 =20 =20 On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek = <michal.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> = wrote: =20
On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo@redhat.com = <mailto: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 =
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. =20 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 =
--Apple-Mail=_B5C5EE46-B870-4828-AD47-B51209767DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 the this, and then the that bug.
=20 =20 The other way around is having a modified bugs which should have been = in post being considered in the build, moved to QE, failing QE, move = back to assigned. Not sure it's much better.
it is when the amount of false positive ON_QA bugs is far less than = amount of forgotten bugs I=E2=80=99m not advocating for it, I=E2=80=99m just saying it was = pointed out that this was the situation before we introduced the hook. Perhaps with the doc police emails it is no longer a relevant point Thanks, michal
=20 =20 =20 =20
=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 <mailto:Devel@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/devel = <http://lists.ovirt.org/mailman/listinfo/devel> >=20 >=20 >=20 > --=20 > Sandro Bonazzola > Better technology. Faster innovation. Powered by community = collaboration. > See how it works at redhat.com <http://redhat.com/>
--Apple-Mail=_B5C5EE46-B870-4828-AD47-B51209767DB1 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:32, 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 Thu, Aug 18, 2016 at 9:19 AM, = Michal Skrivanek <span dir=3D"ltr" class=3D""><<a = href=3D"mailto:michal.skrivanek@redhat.com" target=3D"_blank" = class=3D"">michal.skrivanek@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"><div = style=3D"word-wrap:break-word" class=3D""><br class=3D""><div = class=3D""><div class=3D""><div class=3D"h5"><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" target=3D"_blank" = class=3D"">sbonazzo@redhat.com</a>> wrote:</div><br class=3D""><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" target=3D"_blank" = 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" target=3D"_blank" = 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" target=3D"_blank" = 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 class=3D""><br = class=3D""></div></div></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=99t consider that bug.</div><div class=3D""><br = class=3D""></div></div></blockquote><div class=3D""><br = class=3D""></div><div class=3D"">The other way around is having a = modified bugs which should have been in post being considered in the = build, moved to QE, failing QE, move back to assigned.</div><div = class=3D"">Not sure it's much = better.</div></div></div></div></div></blockquote><div><br = class=3D""></div>it is when the amount of false positive ON_QA bugs is = far less than amount of forgotten bugs</div><div>I=E2=80=99m not = advocating for it, I=E2=80=99m just saying it was pointed out that this = was the situation before we introduced the hook.</div><div>Perhaps with = the doc police emails it is no longer a relevant point</div><div><br = class=3D""></div><div>Thanks,</div><div>michal</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""><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"><div style=3D"word-wrap:break-word" = class=3D""><div class=3D""></div><div class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><span = 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""><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 = data-smartmail=3D"gmail_signature" class=3D""><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></span><span class=3D""> ______________________________<wbr class=3D"">_________________<br = class=3D"">Devel mailing list<br class=3D""><a = href=3D"mailto:Devel@ovirt.org" target=3D"_blank" = class=3D"">Devel@ovirt.org</a><br class=3D""><a = href=3D"http://lists.ovirt.org/mailman/listinfo/devel" target=3D"_blank" = class=3D"">http://lists.ovirt.org/<wbr = class=3D"">mailman/listinfo/devel</a></span></div></blockquote></div><br = class=3D""></div></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> </div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_B5C5EE46-B870-4828-AD47-B51209767DB1--