3 ms·

They should be listed as a kernel contributor based on a miniscule patch. Lines of code modified is a notoriously bad signal for estimating the significance of

They should be listed as a kernel contributor based on a miniscule patch. Lines of code modified is a notoriously bad signal for estimating the significance of software engineering contributions. And at the end of the day, credit is damn near free to give out and volunteer projects ought to let it run like water.

deleted 3y ago
[deleted]
jacquesm 3y ago
That's true, but in this case the contribution really is miniscule and if you look at the actual exchange between the kernel maintainer and the OP it is at a minimum misrepresented in the blog post and on top of that the kernel maintainer put in a bunch of work as well including code changes. OP makes it seem as though something major is at stake here and I just don't see it, it's a four line bug fix for a very old issue on a non-mainstream platform. That doesn't get your name posted next to Torvalds and Cox, though I do support the 'Suggested-by' tag, that would be a nice middle ground. Finally: if you want 'Kernel contributor' on your CV then the last thing you want to do is to mail security patches to that particular mailing list, especially ones that still need work.
- shadowgovt 3y ago
  > it's a four line bug fix for a very old issue on a non-mainstream platform This thinking is what commercial software market dominance is made of. People unwilling to make the software move from the 99% case to the 100% case because those with the authority to hand out credit can't even be bothered to do that. Meanwhile, corporations just pay their people for scutwork, including the unsexy kind like making the software work correctly on a corner case architecture, and while credit isn't given, money is. If anything, credit should be given even more freely for fixing old problems. "How the hell is this bug 6 years old and still here" is a common criticism of open source software. It's hardly putting somebody's name "next to" Torvalds to note that they isolated a buffer overrun and contributed a correction for it.
  - jacquesm 3y ago
    I'm all for the 'Suggested-by' tag but still note that the maintainer did not act in a way that maintainers for the Linux kernel have been acting for pretty much as long as the kernel has existed. Security holes get plugged, credit is secondary to that, and drama over that credit is showing a large misunderstanding about how the Linux kernel has historically dealt with drive by patches, especially small ones.
    - phendrenad2 3y ago
      Sure, but how do we know that's the case here?
      - jacquesm 3y ago
        By reading the email exchange between the OP and the kernel maintainers. Which is materially misrepresented in TFA.
- FartyMcFarter 3y ago
  The contribution is not miniscule. It can take hours or even months to come up with some 1-line fixes. As long as you insist in measuring contributions by the way the patch looks, I can't take that seriously.
- nec4b 3y ago
  How come you didn't fix it? I'm sure it would have taken you only 5 minutes to find it and 2 more minutes to write a fix.

deleted 3y ago

[deleted]

jacquesm 3y ago

That's true, but in this case the contribution really is miniscule and if you look at the actual exchange between the kernel maintainer and the OP it is at a minimum misrepresented in the blog post and on top of that the kernel maintainer put in a bunch of work as well including code changes. OP makes it seem as though something major is at stake here and I just don't see it, it's a four line bug fix for a very old issue on a non-mainstream platform. That doesn't get your name posted next to Torvalds and Cox, though I do support the 'Suggested-by' tag, that would be a nice middle ground. Finally: if you want 'Kernel contributor' on your CV then the last thing you want to do is to mail security patches to that particular mailing list, especially ones that still need work.

shadowgovt 3y ago
> it's a four line bug fix for a very old issue on a non-mainstream platform This thinking is what commercial software market dominance is made of. People unwilling to make the software move from the 99% case to the 100% case because those with the authority to hand out credit can't even be bothered to do that. Meanwhile, corporations just pay their people for scutwork, including the unsexy kind like making the software work correctly on a corner case architecture, and while credit isn't given, money is. If anything, credit should be given even more freely for fixing old problems. "How the hell is this bug 6 years old and still here" is a common criticism of open source software. It's hardly putting somebody's name "next to" Torvalds to note that they isolated a buffer overrun and contributed a correction for it.
- jacquesm 3y ago
  I'm all for the 'Suggested-by' tag but still note that the maintainer did not act in a way that maintainers for the Linux kernel have been acting for pretty much as long as the kernel has existed. Security holes get plugged, credit is secondary to that, and drama over that credit is showing a large misunderstanding about how the Linux kernel has historically dealt with drive by patches, especially small ones.
  - phendrenad2 3y ago
    Sure, but how do we know that's the case here?
    - jacquesm 3y ago
      By reading the email exchange between the OP and the kernel maintainers. Which is materially misrepresented in TFA.
FartyMcFarter 3y ago
The contribution is not miniscule. It can take hours or even months to come up with some 1-line fixes. As long as you insist in measuring contributions by the way the patch looks, I can't take that seriously.
nec4b 3y ago
How come you didn't fix it? I'm sure it would have taken you only 5 minutes to find it and 2 more minutes to write a fix.