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.
Dev investigates and submits patch for known issue affecting him
Maintainer implements different approach saying: “Rather than trying to make the TS_FPR() macro even more complicated to fix the bug, or add more macros, instead add a special-case for 32-bit
kernels. This is more obvious and hopefully avoids a similar bug happening again in future.”
Dev does not show any other correspondence with maintainer, but paraphrases maintainer as saying: “Sorry, I like my version better. If you want to be a Linux kernel contributor, here’s an issue you could fix.”
Dev investigates and submits patch for known issue affecting him
Maintainer implements different approach saying: “Rather than trying to make the TS_FPR() macro even more complicated to fix the bug, or add more macros, instead add a special-case for 32-bit kernels. This is more obvious and hopefully avoids a similar bug happening again in future.”
Dev does not show any other correspondence with maintainer, but paraphrases maintainer as saying: “Sorry, I like my version better. If you want to be a Linux kernel contributor, here’s an issue you could fix.”