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.
cmeerw@programming.dev 1 year ago
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.c
should be updated to use code that’s more similar toptrace-fpu.c
now?ck_@discuss.tchncs.de 1 year ago
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.
RonSijm@programming.dev 1 year ago
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
ck_@discuss.tchncs.de 1 year ago
… illustrating my point.
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.
MajorHavoc@lemmy.world 1 year ago
I just want you to know the votes on your post pretty accurately reflect the ratio of developers I could train or hire as lead developer to those I could not.
If anything, the vote count here skews better than I would have expected.
Hang in there and keep mentoring. It’s thankless, but you ultimately get paid more.