Yes, so people could see my original submission. Then I’ve explained the purpose of the forward when asked, I don’t see any problem with that.

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.

Between the initial patch and the maintainer’s patch there was a private conversation between me and the maintainer (I don’t have access to it because I’ve used my work email and since then I switched companies). I posted my reworked patch only for visibility, since by then they have accepted the maintainer’s patch. But I sent the reworked patch in private to the PowerPC maintainer, before sending it to the powerpc mailing list.

Here is the original patch I sent to the Linux kernel security team: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg221962.html

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.

Yeah, I think my issue was that I was trying to do this the “C” way and this doesn’t fit the Rust ownership model.