Hacker News Reader

Comment by superboum | Hacker News Reader

The kernel documentation defines some tag conventions, one of them is "Suggested-by". Its definition:

  A Suggested-by: tag indicates that the patch idea is suggested by the person named and ensures credit to the person for the idea.
  Please note that this tag should not be added without the reporter's permission, especially if the idea was not posted in a public forum. 
  That said, if we diligently credit our idea reporters, they will, hopefully, be inspired to help us again in the future.

It could have been more appropriate to the situation, I think it's convey better the idea that you have found a solution to a problem, but because you are not familiar with the project, the exact syntax of your patch has not been kept.

Ref: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

View on HN

I haven't compared the patches but a comment below [1] says:

> The only difference between the patch that was accepted and the one that was proposed is where the fix is. In one case it's in an ifdef outside of an if. In the other it's in an inner if statement. That's it. This is a difference in style not a technical difference in the patch at all.

It sounds like the author did quite a bit more than "suggest" the patch idea. They debugged the issue and wrote an entire patch which was accepted with one small change.

1: https://news.ycombinator.com/item?id=37672558

That works, but probably it works better in the context of things that are not reported as security issues where speed and accuracy matter more than form, the kernel maintainers did the right thing by crediting the person as 'Reported-by', your 'Suggested-by' would make things a bit better but clearly isn't what the OP is looking for, they want to be labelled 'Kernel contributor' based on a miniscule patch.

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.

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.

> 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.

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.

Sure, but how do we know that's the case here?

By reading the email exchange between the OP and the kernel maintainers. Which is materially misrepresented in TFA.

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.

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.

Well, they're not going to send in any more work that requires this standard of debugging, so the kernel will remain insecure in those ways. That isn't great, but perhaps we'll each just have our own preferred kernel flavors like how a bunch of us would use Con Kolivas's alternate scheduler back in the day.

And that way, forks being present, attribution is required for copyright and hence, copyleft.

And that's precisely the bit that the OP omitted.

Reply on news.ycombinator.com