Context Around a year and a half ago, I’ve asked my former company for some time to work on an issue that was impacting the debugging capabilities in our project: gdbserver couldn’t debug multithreaded applications running on a PowerPC32 architecture. The connection to the gdbserver was broken and it couldn’t control the debug session anymore. Multiple people have already investigated this problem and I had a good starting point, but we still weren’t sure in which software component the issue lied: it could have been the toolchain, the gdbserver, the Linux kernel or the custom patches we applied on top of the kernel tree. We were quite far away from finding the root cause.
    • cmeerw@programming.devEnglish
      19·
      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. Maybe ptrace32.c should be updated to use code that’s more similar to ptrace-fpu.c now?

        • RonSijm@programming.dev
          10·
          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.

          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

            • RonSijm@programming.dev
              92·
              1 year ago

              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

        • MajorHavoc@lemmy.world
          56·
          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 (up) as lead developer to those I could not (down).

          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.

    • lysdexic@programming.devEnglish
      93·
      1 year ago

      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.