Re: [Xen-devel] [v4][PATCH 11/19] tools: introduce some new parameters to set rdm policy

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 07/02/2015 11:01 AM, Chen, Tiejun wrote:
>> 1. After spending yet another half hour doing research, I haven't found
>> any discussion that concluded we should have the global policy override
>> the local policy
> 
> I also took some time to go back checking this point and indeed this is
> not in that public design. And as I mentioned in another email which is
> following this, I also had a talk to Kevin about this issue, and looks
> this is just concluded from our internal discussion and he didn't post
> this in v2 design again because as you know, that design is about
> something in high level. And as I recall, these discussions can't cover
> everything at that moment because they thought we'd better post a
> preliminary patches to further discuss something since this is really a
> complicated case. So afterwards I sent out two RFC revisions to help all
> guys finalize a good solution. And I can confirm current policy is
> always same from the first RFC, but we didn't see any opposite advice
> until now.

Probably because the reviewers all assumed that the design draft had
been followed, and you didn't make it clear that you'd changed it.

>> 2. The only discussion I *did* find has *you yourself* saying that the
>> per-device setting should override the global setting, not once, but
>> twice; and nobody contradicting you.
>>
>> Maybe there is somewhere else a discussion somewhere where this was
>> changed; but I've already spent half an hour this morning looking at
>> where you said it was (v2 design discussion), and found the opposite --
>> just as I remembered.  I'm not going to look anymore.
>>
>> You have now caused me to waste an awful lot of time on this series that
>> could profitably have been used elsewhere.
> 
> Sorry to this but I just think we already have 2 RFC revisions and 4
> revisions without RFC, and some patches are already Acked, we really
> should overturn this policy right now?

First of all, I think it's easy to change.

Even if it weren't, I already said that I'd be OK with accepting the
patch series with the existing "override" semantics, and without the
"default" semantics, *if* it were renamed to make it clear what was
going on.

But, for future reference, I am not going to approve an interface I
think is misleading or wrong -- particularly one like the xl interface
which we want to avoid changing if possible -- just because time is
short.  One of my own features, HVM USB pass-through, has narrowly
missed two releases (including the current one) because we wanted to be
careful to get the interface right.

>>> Again, I didn't walk into v2 design. So here I don't want to bring any
>>> confusion to you just with my reply.
>>
>> This is your feature, so it is your responsibility to understand and
>> explain why you are doing what you are doing, if only to say "Jan wanted
> 
> Maybe you remember I just posted v1 but looks that was not a better
> design to show this implementation according to some feedback, so Kevin
> issued v2 revision and had a wider discussion with you guys. Since then
> I just follow this version. So I mean I don't further hold these things
> in high level since I just think both policy is fine to me because IMO,
> these two approaches are optional.
> 
>> X to happen because of Y [see $ref]."
>>
> 
> So this is why I said you'd better ask this to Kevin or Jan since I
> can't decide what's next at this point.

Let me say that again: I don't care whether anyone "pulled rank" and
ordered you to do something a certain way.  YOU are the one submitting
this patch.  That means YOU responsible for understanding why they want
it that way, and YOU are responsible for justifying it to other people.
 If you don't understand it at all, it's YOUR responsibility to get them
to explain it, not mine to chase them down.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel