Frankly, I think that's a non-trivial problem to solve: how to get the assumedly better fix while not ruffling the feathers of the more junior contributor so not to discourage on-ramping.
I guess the best way to do it would be to have a co-authored-by tag, or something akin.
> Thanks for your patch, but I wanted to fix it differently. Can you try the patch below and make sure it fixes the bug for you?
Which to me, at least, reads very differently than claiming the author's patch is worse.
[0] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
(Credit to nolist_policy for pointing this out upthread.)
Having seen both sides of that table many times, you can see the value in someone who just gets the shit done. Especially since this was security related and may have had some urgency to get merged before a release. Imagining how much work these guys must have accepting patches you can sympathize with taking some shortcuts.
The maintainer is free to come up with their version and expedite committing it. The point is that if their patch is based on the original author's patch (which in this case it is; they just shuffled a few lines around), then the original author should've been credited as Author or Co-Authored-By.
Complaining about it reeks of a junior developer mentality.
Then you shouldn't contribute to someone else's project.
I didn’t say I’d be pissed if my contributions are turned away. Every project sure is entitled to say - we don’t need your contributions. But that’s not what happened here. They received this blog author’s contributions, suggested revisions - which they seem to have made and spent time on, and then to only flush them out at the end.
By your logic, if you don’t want someone contributing to your project, just ignore the contribution or say that you don’t want them - do not take it without due credit.
You can, of course, fork the project, or do whatever you want with the code.
I always thought a project as big and respected as that of the linux-kernel would have folks who know better, and look out for the best interests of teh project while respecting new-comers. After all they were new when they started contributing?
I dont think anybody in their right mind would advocate for a "not best" solution to be accepted just because a new-comer brought it. The right thing to do would have been - "Here, I have reviewed your patch. This and This are troubling because of this reason. I'd recommend re-writing this like that. Tell me if you need assistance with this, and I can help write that part" and co-author such a patch. That's how you get a good pipeline of future contributors who also care.