<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 21, 2022 at 8:56 PM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Fri, Jan 21, 2022 at 08:39:47PM +0530, Ani Sinha wrote:<br>
> On Fri, Jan 21, 2022 at 20:33 Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>><br>
> wrote:<br>
> <br>
> > On Fri, Jan 21, 2022 at 08:16:01PM +0530, Ani Sinha wrote:<br>
> > ><br>
> > ><br>
> > > On Fri, 21 Jan 2022, Daniel P. Berrangé wrote:<br>
> > ><br>
> > > > On Fri, Jan 21, 2022 at 07:38:35PM +0530, Ani Sinha wrote:<br>
> > > > ><br>
> > > > ><br>
> > > > > On Fri, 21 Jan 2022, Michal Prívozník wrote:<br>
> > > > ><br>
> > > > > > On 1/20/22 18:23, Ani Sinha wrote:<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > On Thu, Jan 20, 2022 at 21:29 Michal Prívozník <<br>
> > <a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a><br>
> > > > > > > <mailto:<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>>> wrote:<br>
> > > > > > ><br>
> > > > > > >     On 1/20/22 16:48, Ani Sinha wrote:<br>
> > > > > > >     ><br>
> > > > > > >     ><br>
> > > > > > ><br>
> > > > > > >     ><br>
> > > > > > >     > AKA kicking the can one more time 🙃<br>
> > > > > > ><br>
> > > > > > >     Well, I should have been more careful and not merge the<br>
> > patch in the<br>
> > > > > > >     first place. Changing API behavior is something we should<br>
> > never do.<br>
> > > > > > ><br>
> > > > > > >     Looking at the code closer, it looks like all callers of<br>
> > this function<br>
> > > > > > >     would need to ignore the reported error so that their<br>
> > behavior is not<br>
> > > > > > >     changed. At this point, does it make sense to report an<br>
> > error in the<br>
> > > > > > >     function?<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > The callers can decide what do with the error raised by the<br>
> > function. We<br>
> > > > > > > should not write functions that cannot fail.<br>
> > > > > > ><br>
> > > > > ><br>
> > > > > > But that's not what the commit does, is it. It changed some public<br>
> > APIs<br>
> > > > > > from best effort to fail early.<br>
> > > > ><br>
> > > > > That is the side effect and I consider it as a bug. Imagine we add<br>
> > some<br>
> > > > > more code into that function tomorrow and there is an error path. Now<br>
> > > > > because of this bug, we will have to ignore the error condition and<br>
> > not<br>
> > > > > report it. How ridiculous is that?<br>
> > > > ><br>
> > > > > We should have kept the patch as is and fix the callers so that the<br>
> > public<br>
> > > > > APIs were not broken.<br>
> > > ><br>
> > > > That is not the libvirt approach. Our #1 priority is public API<br>
> > > > compatibility, everything else is subservient to that. So when we<br>
> > > > have a regression we fix that in the quickest possible way. Simply<br>
> > > > reverting the broken patch><br>
> > ><br>
> > > (a) I take exception to the fact that the patch reverted was "broken".<br>
> ><br>
> > Did you actually read the bug report in the first message in this<br>
> > series ? An end user hit a behaviour regression breaking the<br>
> > installation process, and was caused by the patch that's been<br>
> > reverted.<br>
> <br>
> <br>
> No I did not read the bug report because it required me to create an<br>
> account and then login. I do not have my redhat BZ account credentials<br>
> handy.<br>
<br>
Urgh, sorry I missed that the BZ was private. Private BZs are not<br>
supposed to be listed in commit messages for precisely the reason<br>
that people can't see them. The commit message should have showed<br>
the problem listed in the private BZ description instead.</blockquote><div dir="auto"><br></div><div dir="auto">Turns out even if I logged into BZ with my old account credentials ( I couldn't find the password, so reset it) I still can't access the bug info:</div><div dir="auto"><br></div><div dir="auto"><div id="error_msg" class="throw_error" style="margin-bottom:2em;padding:0.5em 1em;float:left;border:1px solid red;max-width:98%;min-width:98%;margin-top:1em;font-family:"Open Sans",Helvetica,sans-serif;font-size:inherit!important;background-color:white;color:rgb(0,0,0)" dir="auto"><p style="font-family:"Open Sans",Helvetica,sans-serif">You are not authorized to access bug #2041610.</p><p style="font-family:"Open Sans",Helvetica,sans-serif">Most likely the bug has been restricted for internal development processes and we cannot grant access.</p><p style="font-family:"Open Sans",Helvetica,sans-serif">If you are a Red Hat customer with an active subscription, please visit the <a href="https://access.redhat.com/" style="text-decoration:none;font-family:"Open Sans",Helvetica,sans-serif;outline:none!important;color:darkblue">Red Hat Customer Portal</a> for assistance with your issue</p><p style="font-family:"Open Sans",Helvetica,sans-serif">If you are a Fedora Project user and require assistance, please consider using one of the <a href="https://fedoraproject.org/wiki/Communicate" style="text-decoration:none;font-family:"Open Sans",Helvetica,sans-serif;outline:none!important;color:darkblue">mailing lists</a> we host for the Fedora Project.</p></div><br class="Apple-interchange-newline" style="color:rgb(0,0,0)"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
</blockquote></div></div>