Comment Re:Arsehole (Score 3, Insightful) 1051
No. This isn't because Linus can't fire him. This wasn't Linus carefully picking his words to get his point across. This was an out of control rant and his explanations about that being his style are ones I do not accept as valid. They seem to be nothing more than excuses for a criminal lack of self discipline.
Mr. Chehab is either competent and made a mistake, or he is not competent and this is chronic. In the latter case, I can understand frustration, but this is exactly what self discipline is for. Because even if it was total incompetence, anger is not ever a valid response to incompetency. I bolded that because it's important. It's never appropriate in response to incompetence. Never. Not by anybody. Regardless of your self-professed management style. Regardless of the stakes. It is a failure of one's personal self discipline, and it is always... always self defeating.
Anger is a proper response in the face of willfulness or maliciousness. And looking at the thread, and in reading quite a number of other threads involving Mr. Chehab, it is clear that he was being neither willful nor malicious. Anger is part of the "fight or flight". It's an adjunct to combat, and the words Linus used were clearly combative. Combat is a response to combat - otherwise you are being an aggressor. In other words, Linus was being nothing more than a schoolyard bully picking on someone for no better reason than he could. It's that simple.
You can be stern, uncompromising, and even lay out consequences for ongoing failure without the anger and get the point across just as well. Here is how Linus' letter should have read:
Are you saying that pulseaudio is entering on some weird loop if the returned value is not -EINVAL? That seems a bug at pulseaudio.
Mauro, this sounds like excuse-making.
It's a bug alright - in the kernel. You've been a kernel maintainer too long to not know that the first rule of kernel maintenance is that if a change results in user programs breaking then it's a bug in the kernel. We never EVER blame the user programs. Don't do that again.
To make matters worse, the entire commit (f0ed2ce840b3) is substandard. You know that ENOENT is not a valid error return from an ioctl. Never has been, never will be. ENOENT means "No such file and directory", and is for path operations. ioctl's are done on files that have already been opened, there's no way that ENOENT would ever be valid.
So, on a first glance, this doesn't sound like a regression, but, instead, it looks tha pulseaudio/tumbleweed has some serious bugs and/or regressions.
I don't want to see this sort of excuse-making from a kernel maintainer again.
I'm going to apply Rafael's patch directly myself. My taking time and effort to apply fixes directly for problems you've introduced means your work has reduced overall efficiency. Make sure that doesn't happen again.
Seriously.
WE DO NOT BREAK USERSPACE!
I'm frustrated because your whole email was wrong, and the patch that broke things was substandard. The fact that you seem to try to make *excuses* for breaking user space and blame some external program that *used* to work, is just not how we work.
A Better Linus