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.
Unfortunately I don’t have my original patch, because I only sent that to the Linux security mailing list. I don’t think it’s a stupid thing to want to have code in the kernel, especially after spending all my time debugging this issue. The fix was trivial once I’ve pointed to the exact place where the buffer overflow happened and I should have received credit for all my effort.
You did receive credit. A good bug report allows reproducing and ideally fixing the issue - which can involve considerable effort. This is the difference between your report, and the one you linked from 6 years ago.
Like I said, I’d probably have added an additional thanks for that in my commit message - but I’m unfamiliar with the kind of reports this particular subsystem typically receives, so it is quite possible your report is just something average coming in there.
I personally prefer to include code suggesting a fix in my bug reports - but I usually don’t expect it to be just merged as I’m not familiar with surrounding code. I also don’t expect that to receive an additional mention - it’s just part of the report, and is often cleaner in demonstrating the issue than a problem description.
I don’t think it’s a stupid thing to want to have code in the kernel, especially after spending all my time debugging this issue.
The way that you jumped straight onto broadcasting drama when your very first Linux kernel patch stumbled on the code review stage is a major red flag.
I would hate to work with you because I would feel that I would be risking being subjected to a very public character attack each time I had to review one of your patches.
The way that you jumped straight onto broadcasting drama
I’m not broadcasting drama, I’m sharing my side of the story on my personal blog and distribute it to other social media platforms.
your very first Linux kernel patch stumbled on the code review stage
The patch didn’t stumble on the code review stage, the PowerPC maintainer didn’t want to accept patches from me and implemented his own fix.
I would hate to work with you because I would feel that I would be risking being subjected to a very public character attack each time I had to review one of your patches.
Why would you hate people who would describe their interactions with you? The only reason I see is that you would hate how you’ve dealt with them.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Unfortunately I don’t have my original patch, because I only sent that to the Linux security mailing list. I don’t think it’s a stupid thing to want to have code in the kernel, especially after spending all my time debugging this issue. The fix was trivial once I’ve pointed to the exact place where the buffer overflow happened and I should have received credit for all my effort.
You did receive credit. A good bug report allows reproducing and ideally fixing the issue - which can involve considerable effort. This is the difference between your report, and the one you linked from 6 years ago.
Like I said, I’d probably have added an additional thanks for that in my commit message - but I’m unfamiliar with the kind of reports this particular subsystem typically receives, so it is quite possible your report is just something average coming in there.
I personally prefer to include code suggesting a fix in my bug reports - but I usually don’t expect it to be just merged as I’m not familiar with surrounding code. I also don’t expect that to receive an additional mention - it’s just part of the report, and is often cleaner in demonstrating the issue than a problem description.
I think you’ll be happier in the long run if you can forgive and move on.
The way that you jumped straight onto broadcasting drama when your very first Linux kernel patch stumbled on the code review stage is a major red flag.
I would hate to work with you because I would feel that I would be risking being subjected to a very public character attack each time I had to review one of your patches.
I’m not broadcasting drama, I’m sharing my side of the story on my personal blog and distribute it to other social media platforms.
The patch didn’t stumble on the code review stage, the PowerPC maintainer didn’t want to accept patches from me and implemented his own fix.
Why would you hate people who would describe their interactions with you? The only reason I see is that you would hate how you’ve dealt with them.
I’m not broadcasting drama, I’m sharing my side of the story on my personal blog and distribute it to other social media platforms.
That’s literally broadcasting drama.