Re: [Xen-devel] [PATCH for-4.12] passthrough/vtd: Drop the "workaround_bios_bug" logic entirely

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.03.19 at 16:06, <george.dunlap@xxxxxxxxxx> wrote:
> On 3/26/19 1:39 PM, Jan Beulich wrote:
>>> This is a regression in 4.12 and needs resolving.  The choice is between
>>> reverting dcf41790 or removing this code, and reverting dcf41790 is
>>> obviously not a valid thing to do.
>> 
>> As explained before, there was an earlier regression, which - if it
>> had been noticed in time - would have made all versions from 4.2
>> to 4.11 behave like 4.12 without your change. This behavior was
>> intended by the original author. Ripping the code out by convincing
>> people to bypass normal review flow is, well, not very nice to put it
>> mildly.
> 
> I would like to say, I thought Andy tried to be very scrupulous here.
> He had two different R-b's from people familiar with the code, and an
> Ack from the release coordinator. I think he would have been justified
> in checking the patch in on that basis,

Hmm, a very interesting position - maintainer acks are then not
necessary anymore. I think in that case quite a few of my patches
could have been committed long ago. In fact, had I been fast
enough (just as was the case here) I could then have committed
"x86/mtrr: fix build with gcc9" as well, since Andrew's sort of
objecting response arrived only about a week after I had received
Wei's and Roger's R-b.

While taking that position would eliminate some of the gigantic
stalls I'm observing for some of my patches, I think a more formal
weakening of the need for maintainer acks should then first be
put in place.

> but just to make sure he was
> doing the right thing, he asked someone else from "The Rest" (me) to
> double-check to make sure.

But there was no real urgency: The supposedly regressing patch was
put in back in August. So there was an entire half year to notice and
work around the issue. (I was made vaguely aware of it by Andrew
a few days before this patch arrived.)

> Given the difference between how the two of you approach this sort of
> thing, I understand why you might interpret that in a negative light.
> But I don't think it's in the best interest of the project for people to
> be completely risk-averse in this sort of situation.  We have source
> control for a reason: If the change turns out to have been wrong, we can
> revert it.

Sure, I can accept taking this position in the middle of a dev cycle.
I don't think it's appropriate immediately prior to a release.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel