<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 13 nov. 2020 à 13:17, Radosław Piliszek <<a href="mailto:radoslaw.piliszek@gmail.com">radoslaw.piliszek@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Nov 13, 2020 at 12:09 PM Herve Beraud <<a href="mailto:hberaud@redhat.com" target="_blank">hberaud@redhat.com</a>> wrote:<br>
><br>
> Thanks for the heads up.<br>
><br>
> Notice that I just submitted a series  of patches [1] to fix all masakari's stable branches, feel free to abandon these patches if they aren't needed anymore.<br>
><br>
> [1] <a href="https://review.opendev.org/#/q/topic:fix-libvirt-focal+(status:open+OR+status:merged)" rel="noreferrer" target="_blank">https://review.opendev.org/#/q/topic:fix-libvirt-focal+(status:open+OR+status:merged)</a><br>
><br>
<br>
Ah, sorry, did not notice that.<br>
I just went with [1] removing the pkg to avoid the naming issue altogether.<br></blockquote><div><br></div><div>No problem</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
My question is whether we could detect such issues more proactively?<br></blockquote><div><br></div><div>Good question... I don't think that this kind of a check should be hosted on the release management side.</div><div>Here our issue is more an environment issue, It's due to the fact that we decided to run the job `publish-openstack-artifacts` on ubuntu-focal, so to detect this kind of issue early I think that jobs on the projects side should rely on ubuntu-focal too. I'm not a Zuul expert and I don't know if it is possible to add a condition based on the branches (per example) to choose the right env (focal or not). By following this way I guess it could be possible to fail early on the project side, and it could allow you to fix this kind of issue well before proposing a new release. In other words, if projects's jobs env are aligned with release management our job we could catch them early.</div><div><br></div><div>We have other scenarios to consider. These are when no patches haven't been merged since a while on projects side, and where a release is proposed, in this case even if environments are aligned, in this case we aren't able to detect this kind of issue, and they will continue to occur during publication, as in this case.</div><div><br></div><div>It could be worth it to involve the infra team to see how to fail early.</div><div><br></div><div>Thoughts?<br></div><div><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[1] <a href="https://review.opendev.org/762637" rel="noreferrer" target="_blank">https://review.opendev.org/762637</a><br>
<br>
-yoctozepto<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Hervé Beraud</div><div>Senior Software Engineer at Red Hat</div><div>irc: hberaud</div><div><a href="https://github.com/4383/" target="_blank">https://github.com/4383/</a></div><div><a href="https://twitter.com/4383hberaud" target="_blank">https://twitter.com/4383hberaud</a><br></div><div>-----BEGIN PGP SIGNATURE-----<br><br>wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>v6rDpkeNksZ9fFSyoY2o<br>=ECSj<br>-----END PGP SIGNATURE-----<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div>