On Mon, Jul 18, 2022 at 09:53:23AM +0100, Russell King (Oracle) wrote: > On Sat, Jul 16, 2022 at 04:13:45PM +0300, Vladimir Oltean wrote: > > On Sat, Jul 16, 2022 at 12:43:00PM +0100, Russell King (Oracle) wrote: > > > In the first RFC series I sent on the 24 June, I explicitly asked the > > > following questions: > > (...) > > > I even stated: "Please look at the patches and make suggestions on how > > > we can proceed to clean up this quirk of DSA." and made no mention of > > > wanting something explicitly from Andrew. > > > > > > Yet, none of those questions were answered. > > > > > > So no, Jakub's comments are *not* misdirected at all. Go back and read > > > my June 24th RFC series yourself: > > > > > > https://lore.kernel.org/all/YrWi5oBFn7vR15BH@xxxxxxxxxxxxxxxxxxxxx/ > > > > I don't believe I need to justify myself any further for why I didn't > > leave a comment on any certain day. I left my comments when I believed > > it was most appropriate for me to intervene (as someone who isn't really > > affected in any way by the changes, except for generally maintaining > > what's in net/dsa/, and wanting to keep a clean framework structure). > > Also, to repeat myself, blaming me for leaving comments, but doing so > > late, is not really fair. I could have not responded at all, and I > > wouldn't be having this unpleasant discussion. It begs the question > > whether you're willing to be held accountable in the same way for the > > dates on which you respond on RFC patches. > > > > > I've *tried* my best to be kind and collaborative, but I've been > > > ignored. Now I'm hacked off. This could have been avoided by responding > > > to my explicit questions sooner, rather than at the -rc6/-rc7 stage of > > > the show. > > > > I think you should continue to try your best to be kind and collaborative, > > you weren't provoked or intentionally ignored in any way, and it isn't > > doing these patches any good. > > And yet again, I don't have answers to many of those questions... which > just shows how broken this process is, and how utterly pointless it is > 0to ask any questions in this area. > > My conclusion: you don't care one bit to even answer questions until > there's a chance that patches that you disagree with might be merged, > and oh my god, you've got to respond to stop that happening because you > might disagree with something. You can't do the collaborative thing and > respond when someone asks explicit questions about how things should be > done. > > I'm not going to let this go. I'm really pissed off by this and you > are the focus of my frustration. The hypothesis that you put forward is that I'm sabotaging you by not responding to RFCs, then leaving comments when you submit the patches proper, just so that they're delayed because I don't agree with them; and that the process is broken because it allows me to do just that and get away with it (for fun, I assume?). So first off, you sent the first RFC towards 2 people in To:, and 19 people in Cc:. I was one of the people in Cc. You didn't ask *me* any explicit question. In fact, when you did, I responded within 5 hours: https://lore.kernel.org/linux-arm-kernel/20220707154303.236xaeape7isracw@skbuf/ Then, why did I not respond earlier to questions I had an opinion on? Based on prior experience, anything I reply to you has a chance of inflaming you for reasons that are outside of my control, and the discussion derails and eventually ends with you saying that I'm being difficult and you're quitting for the day, week, month, kernel release cycle or what not. I'm not saying that's my fault or your fault in general, it's just a statistical observation based on past interactions, and it looks like this one is no different. With regard to this topic, there was ample opportunity for the patch set to come to a resolve without my intervention, and I decided that the best way to maximize the chances of this discussion not going sideways is to not say anything at all, especially when I don't need to. Gradually, the opportunity for the patch set to resolve itself without my intervention diminished, and I started offering my feedback to the code. It's perhaps necessary of me to not let this phrase of yours unaddressed, because it is subtly part of your argument that I'm just trying to delay your patches as part of a sabotage plot: | The only thing that delayed them was your eventual comments about | re-working how it was being done. Let's not forget that I did *not* request you to rework the implementation to use software nodes. I simply went with the code you originally proposed, explained why it is unnaturally structured in my view, asked you why you did not consider an alternative structure if you're not willing to make phylink absorb the logic, then you said you'd be happy to rework using software nodes. https://lore.kernel.org/netdev/20220707193753.2j67ni3or3bfkt6k@skbuf/ My feedback was very actionable, I put forward a working prototype for using software nodes that did consume time for me to write, I was not being handwavy in any way. More importantly, you agreed with it and are using it now. And all of that happened during RFC stages. To ignore these facts when you state that I respond only to non-RFC patches is a lie by omission. I give feedback to code in the order of importance. Now was the time to point out that (a) I don't want to add support for the defaulting mode on CPU ports for drivers that didn't have it previously, and (b) I'd like to keep the current implementation of the defaulting feature as "don't register with phylink" as the default, with just an opt-in to create the software node. Drivers can opt into that behavior as need shows (breakage reports). Again, this is all extremely actionable feedback, and rather minor in the grand scheme of things. So I'm sorry, but your frustration expressed towards me for ignoring RFC patches *is* misdirected and there's nothing I will consider changing. If the discussion derailed now due to me it doesn't mean it wouldn't have derailed earlier. There are still many people who could have said more things than they did, and yet, I'm not even blaming them for not doing that. There is a chapter in a book by Robert Cialdini called "Influence: The Psychology of Persuasion" which discusses social proof, the mechanism through which people tend to do what others do when otherwise unsure. I'm paraphrasing, but there is a paragraph discussing what can be done when social proof works against you, for example you're being attacked on the street, you ask for help and nobody appears to do anything except for passing by. Summarized, you should ask for very specific things, point to people, say names, rather than get frustrated that the crowd does nothing. > Well, its now too late to do anything about this. This is going to miss > this cycle. It might get in next cycle, and whoopy do, for a kernel > that's very likely to be a LTS. Given the lack of testing that sounds > like a complete and utter disaster. One that was entirely avoidable had > feedback been given EARLIER in this cycle. If your patch set was a silver bullet to avoid breakage, that would have maybe changed things a little, but it isn't. For any driver that might boot using a DT blob with the defaulting feature for the CPU port, there is a gamble to be taken whether the better thing to do is to unleash phylink at it unattended or to let it be. Obviously having a driver maintainer assist phylink would be the correct thing, but until the board in question reaches a maintainer, chances are it will probably reach a user. What I'm trying to obtain in terms of changes is that the user can at least correlate the breakage he's seeing with a dmesg warning message that clearly indicates what phylink or DSA tried to do in lack of clear DT description.
