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.
  • aard@kyu.de
    0·
    1 year ago

    Somebody is pretty salty for no good reason. The maintainers own patch is nicer code than the suggested patch - and the change is small enough that there just isn’t anything available to guide the reporter to a better solution without wasting everyone’s time.

    I’d probably have added a thanks for debugging effort into the commit message myself - but “please accept my patch because I want to have code in the kernel” is a very stupid thing to say, and the maintainer offering a suitable problem to fix is more than I’d have done in that situation.

    • SWW13@lemmy.brief.guru
      2·
      1 year ago

      As someone who had a mildly unpleasant interaction with kernel folks, I can totally understand the issue.

      This is one of the very few open source projects I had the feeling they don’t appreciate new contributers. There is no on boarding material available and picking the wrong subproject mailing list results in being ignored. You have to spend days without any possibility of help and if your are lucky you get mentioned as a reporter. For the next issue you start from square one as there was no guidance, so you could only learn the bare minimum.

      So yeah, his patch may be underwhelming. But the help and credit he got for days or weeks of unpaid work was basically nothing. You may be okay with spending days and only getting credits for the bug report, but I suspect many aren’t and will not contribute again after such an experience. And post like this try to point out the issue they have and why many people won’t contribute to the kernel ever again.

      • aard@kyu.de
        1·
        1 year ago

        So yeah, his patch may be underwhelming. But the help and credit he got for days or weeks of unpaid work was basically nothing. You may be okay with spending days and only getting credits for the bug report, but I suspect many aren’t and will not contribute again after such an experience.

        Especially in this particular case the effort is in debugging the problem, not doing the actual fix - which is the bug report, where he got credited for. lkml is not the place for “how I debugged this problem” - that’d be what goes into his blog. And if you look around you’ll see a lot of “how I helped solving this problem” kind of blog posts.

        This change is so simple that guiding him to do it in a good way would involve fixing it yourself in the explanation - and then you’d not show the code so he can do it himself? That’s just silly. If he cares about that he came out of that with quite a bit of experience on how to handle it the next time - and he mentions he even got an (assumed to be starter friendly) other issue suggested if he wants to have code in the kernel.

        From the perspective of hiring people he turned this from a “nice work debugging a problem, might be a useful candidate” to “tries getting low quality code merged for vanity reasons, let’s avoid that guy”

  • jet@hackertalks.comEnglish
    0·
    1 year ago

    Regardless of deserved credit your reputation in the kernel community will be that of a drama llama at least for awhile. Making a mountain out of a mole hill, will be remembered, does not play well with others.

    I’m not saying you don’t deserve credit, but the method you went about emoting over this event will be noticed by community managers, not just the kernel community. Be aware of how your reputation is developed. Lots of us had to eat some humble pie in our career development.

    If you had spun this in your personal blog on how you helped fix a kernel bug, and spoke of the positives, then you would be seen as more of a team player, plays well with others, doesn’t get bogged down on small issues.

    Our character isn’t defined when times are good, but with how we deal with adversity.

    • 1rre@discuss.tchncs.de
      1·
      1 year ago

      There’s a difference between being a team player and a subservient pawn though - if the maintainer wanted to play as a team they would’ve suggested changes to the patch and accepted OP’s PR. As it happens they didn’t as they clearly have some sort of a power/superiority complex or something, or at best are dismissive of others to the detriment of the project they work on