Or future employers. All the wrangling about "this guy should be selfless and just be happy he made the world a better place" is bonkers. He lobbied his job to give him time to put in a bunch of highly technical work to improve the kernel. Would it really be so bad to acknowledge him as a contributor? How in the world is his work not a contribution?
"""
Solution taken from arch/powerpc/kernel/ptrace32.c
---
arch/powerpc/kernel/ptrace/ptrace-fpu.c | 31 +++++++++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
"""
You really consider this a contribution? You genuinely want to call someone submitting this a kernel contributor and imply they know anything about the code? I mean, I get the social angle of trying to build each other up and do each other favors but in the long run we're doing more harm than we are good by warping the meaning of the title
I consider it a great first contribution. Dude took initiative at his job to try to make his and his teammates' lives easier, investigated a super technical issue, found prior art and built on it, sought help on the list, and tried to shepherd it to get it merged. It was significant effort, and he in no way had to do it. He definitely didn't need to upstream it.
The amount of energy wasted in this thread on the meaning of "contributor" could boil me water for tea. Bewildering, honestly.
Reporting a security issue is not the place for seeking help on the list and shepherding. The idea behind the patch was written simpler by others because the original patch was both technically unacceptable to the maintainer and not cleared for inclusion in the kernel (no Signed-off-by).
He posted to security out of an abundance of caution, but it's hard to see how this could be a significant security issue. Feels unfair to punish him for being considerate here.
Also kernel workflows are not intuitive. I don't have any idea what signed-off-by is or how to get it. Don't you post to the list? What else would you do? Would it have been better for Miculas to spend time researching kernel workflows while this "security issue" remained unpatched? Feels like there's not really a way for him to win here.
> original patch was both technically unacceptable to the maintainer and not cleared for inclusion in the kernel (no Signed-off-by)
Crediting as a co-author is a good compromise here, I would say.
