The linux kernel isn't a reward and while I empathize with the OP I would absolutely prefer a better solution to maintain than one from the community. So the maintainer was well within their rights.
That said, it's so easy to just give people who contributed to the fix attribution, in Node.js we make a point of trying to give credit in release notes and add `Co-Authored-By:` to PRs where we took _some_ work people did in PRs and adapted it.
When you maintain something for a while, credit often stops being important to you (you _are_ the maintainer of the area after all) so it's hard to remember that for new contributors it's often very important.
Totally a loss for OP and that part of linux that the maintainer wasn't more attentive to the fact sharing credit (especially when deserved like in this case) was important to OP.
I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!". This is not how a project reliant on community efforts could sustain itself.
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.
> I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!"
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.
We can't really know as we can't see the author's patch, but given that (i) the guy answering is responsible for the whole CPU architecture in Linux and (ii) the author mourns his putative contributor badge but does not criticize the other patch, that's a bet I'm ready to take.
A pull request and some comments to help the author understand what needs to be adjusted is a common way to handle this with the projects that I work with.
Why? Theres no expectation for you to put in a lot of effort, and if in the hands of a domain expert, could have taken minimal effort. I'm sure everyone has had PRs that could have been resolved in minutes if the submitter had reached out first.
Complaining about it reeks of a junior developer mentality.
On the other hand this can lead to getting stuck in a never ending code-review ping-pong game.
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.
Nobody's saying the maintainer should have to do a never-ending code review ping pong game.
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.
> I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!".
Then you shouldn't contribute to someone else's project.
It is not “their” project now is it?!
This attitude never gets anywhere productive. It only encourages gatekeepers.
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.
... and their results of forward regression testing.
There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution. Ignoring that the maintainer literally moved one line of code (of about forty additions) and "contributed" it with himself as the author.
> There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution.
I don't really understand that either. Someone found a problem, researched it, found and tested a solution, voluntarily offered a patch, and everyone wants to pretend that it was nothing? "It was only x lines", "it was a simple/trivial patch to an obscure project", "It wasn't done in the exact way they wanted it". What is wrong with some people! It was a bug that was reported years ago but nobody took the time to fix it. This guy put in the work and delivered, which in the end is what matters.
Since text in commit messages is free, a more accurate tag hurts noone but keeps the spirits up and encourages future work: Based-on-work-by, Investigated-by, ...
Reported-by is more of a participation medal because it can mean anything including "yo dawg, kernel crashes when I look at it wrong"
But that's only credit for finding the bug, not fixing it. He put quite a lot of work into fixing the bug, and that credit got stolen by someone who merely rewrote his fix.
That said, it's so easy to just give people who contributed to the fix attribution, in Node.js we make a point of trying to give credit in release notes and add `Co-Authored-By:` to PRs where we took _some_ work people did in PRs and adapted it.
When you maintain something for a while, credit often stops being important to you (you _are_ the maintainer of the area after all) so it's hard to remember that for new contributors it's often very important.
Totally a loss for OP and that part of linux that the maintainer wasn't more attentive to the fact sharing credit (especially when deserved like in this case) was important to OP.