Did a bit more digging through the mailing list (also looking through the links posted on the HN thread), and to me it looks a bit weird.
OP came up with an initial patch (Wed, Jun 1, 2022 at 12:36 PM) that wasn't deemed to be good enough to be merged. Maintainer came up with a different patch (Tue, 7 Jun 2022 00:34:56 +1000) saying "but I wanted to fix it differently". OP then posted a reworked patch (Fri Jun 10 17:15:49 AEST 2022) that looks a lot more similar to the maintainer's patch.
The maintainer's patch and OP's reworked patch look quite similar, but from what I can see from the mailing list, the maintainer actually came up with that approach, and OP didn't then credit the maintainer in his reworked patch. @kairos@programming.dev can you please clarify, what am I missing?
Between the initial patch and the maintainer's patch there was a private conversation between me and the maintainer (I don't have access to it because I've used my work email and since then I switched companies). I posted my reworked patch only for visibility, since by then they have accepted the maintainer's patch. But I sent the reworked patch in private to the PowerPC maintainer, before sending it to the powerpc mailing list.
I think it is common knowledge by now that the kernel community is a rather toxic space where abuse and elitism are the norm rather than the exception. If you are unwilling to put up with that, it's probably the wrong community for you to join.
I am not really seeing any toxic behaviour here.
OP's patch was largely based on code in
ptrace32.c, but that code actually looks quite bad. So maintainer applied a better fix. Maybeptrace32.cshould be updated to use code that's more similar toptrace-fpu.cnow?So maintainer applied a better fix.
That in itself is the problem. If the kernel community wants to attract new contributors, mentorship is important and appreciation of effort is important, despite the result of that effort not being up to par yet.
The general consensus in kernel space is to "only care about the code" (to quote Linus Torvalds himself) and not about about people, while in reality when two human beings interact with one another, it's never "just about the code".
The kernel is already suffering from this behavior. The majority of people contributing do so for money. Hobbyists who contribute out of passion in their free time have already become a side show, being pushed out more and more by the ever-present elitism of people who can spend 50h a week becoming experts. On the other hand, the number of people willing to tolerate a hostile work environment just for money is decreasing rapidly.
The kernel code is already deteriorating, code is being merged without anyone ever reviewing it as nobody has the time, energy or patience. Unless the kernel community starts changing from the inside out, we will see real problems popping up more and more in the next ten years.
That in itself is the problem. If the kernel community wants to attract new contributors, mentorship is important and appreciation of effort is important, despite the result of that effort not being up to par yet.
Well it depends on the quality of the PR. If there are minor things wrong, you can point them out the the contributor and help them get their PR to a level you want..
If the PR is "Ok, thanks for pointing out where the issue is, but I'm going to have to rewrite your solution entirely" - what is the maintainer supposed to do? Take their PR, overwrite the solution, and git squash them together so the original contributor gets "credit" in form of being in the git history?
I doubt the maintainer would even consider that the contributor would feel "belittled and angry" if their fix wasn't accepted at face value, or if they didn't get enough credit would write an angry blog post about it. This whole article could have just been a report of "How I found a bug in the Kernel and helped fix it" - instead of something this negative
I doubt the maintainer would even consider that the contributor would feel "belittled and angry"
... illustrating my point.
This whole article could have just been a report of "How I found a bug in the Kernel and helped fix it" - instead of something this negative
I disagree. If noone spoke out about Linus Torvalds calling people "dumb fucks", he would still be doing it. So criticism about how the community functions and which behavior is tolerated or even rewarded is essential if we ever want things to change. Did the author do the best job with this article? Probably not. That does not invalidate his experience though.
This whole article could have just been a report of “How I found a bug in the Kernel and helped fix it” - instead of something this negative
I disagree. If noone spoke out about Linus Torvalds calling people “dumb fucks”, he would still be doing it.
It's kind of a leap from "not accepting a PR because the maintainer thought the code wasn't good enough to accept it at face value - and the maintainer apparently didn't care enough to give the contributor an extended code-review on how to fix it" vs "calling people “dumb fucks”"
If a maintainer get a PR that's bad and it would take an hour to write an explanation on how to fix it - and then hoping the end-result from the contributor is as expected, otherwise he'll have to write another explanation on how to fix it and go back and forth for a while - vs - just spending that hour rewriting the fix himself - I'm pretty sure most maintainers just do it themselves.
When you actually work for a company and you're working with other (junior) devs, you should go for the option of educating them on what's wrong with their PR... But in this case - I don't even know if the maintainer is doing this as a paid job or just in their spare time - but either way why would the maintainer spend time getting the PR right if it was apparently far off.
Did the author do the best job with this article? Probably not. That does not invalidate his experience though.
I didn't say his experience was invalid, but his experience probably isn't unusual. He could've taken this experience as "I contributed the QA and diagnosing part of this bugfix, but my code wasn't up to par. Next time before submitting some random fix for a bug that I found (that wasn't even "Up for grabs") (or discussed how it should be fixed at all) - I should contact the maintainer first" - Instead it seems he found a bug, didn't really report or communicate about it, because he wanted to race for a fix himself because he wanted to get recognition for actually creating the code the fixed the bug
I think it is common knowledge by now that the kernel community is a rather toxic space where abuse and elitism are the norm rather than the exception.
Even in the blog post's very one-sided account of the issue, there isn't even a hint of elitism or toxic behavior. There was a bug report, the reporter submitted a patch, the patch was faulty and unusable, and the maintainer stepped in to put together a working fix. That's it.
I submitted a pull request to Vim and the maintainer thanked me, tweaked it, and my name is not in the commit history because of it. I use to be bitter about it, if only a little. So I know how you feel but I put significantly less time into mine so the magnitude of the feeling is much smaller for me. My name is still there in the GitHub pull request though. Just like your name is still in the commit itself and in the mailing list. Try not to fret too much about the specifics of your name being in the author field. It's really just a technical detail.
It sucks but it is what it is. I don't think treating this like you were slighted is appropriate.
Here is the original patch I sent to the Linux kernel security team: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg221962.html
So you have just re-posted an old email to the mailing list just so you can link to it, likely confusing everyone on that mailing list.
Yes, so people could see my original submission. Then I've explained the purpose of the forward when asked, I don't see any problem with that.
