[jacquesm]

That's because it is a tiny fix. To ask for credit as a contributor makes it seem as though that was the whole goal and that's why the OP feels 'robbed' as though this is a thing of great value that has been taken away from them.

That's not how I interpret the contents of the exchange:

https://www.mail-archive.com/[e-mail]/m...

Could the kernel maintainer have handled this better? Probably yes. Was the OP robbed? In my opinion, no, their work was credited and the fix is so small it doesn't warrant elevating the OP to 'Kernel contributor' which is typically reserved for more substantial contributions, not bug fixes of a few lines.

Another comment has a nice middle ground in the form of the 'Suggested-by' tag which I think would have been an improvement. I've got a little project on the go and I'm meticulous about crediting people but the context is entirely different there, nobody is going to hold up my project to claim they are a contributor on their CV so I'm fine with the kernel maintainers keeping the list of 'kernel contributors' manageable.

[phendrenad2]

I don't know if you've been in the open-source space for very long, because this is not how it works. It's pretty standard to work very hard to give credit (and not some silly "reporter" credit) to the first person to show up with a working patch for an issue (as long as they are willing to work with the maintainers and make requested changes), because it builds goodwill in the community and encourages contributions. Of course, the kernel maintainers are free to break that social compact, but it's still "robbing" someone of what social norms lead one to expect. And this "robbery" isn't a victimless act, either. Finding a high-complexity (and it was, don't confuse yourself) issue and solving it is a good undertaking that shows that you're a good developer, and also brings some spotlight to the company you represent, which can be good for recruiting and developer relations.

Source: I have asked this question on HN before: https://news.ycombinator.com/item?id=31225599

[jacquesm]

But: it wasn't a working patch, it was mailed to a security mailing list alerting, and it wasn't properly signed off as required for inclusion. Those things alone make the expectations for credit strange. LKML has its own set of very specific rules around this stuff.

[phendrenad2]

Of course, this all makes perfect sense if you live inside the LKML bureaucracy. From the outside it just seems bonkers. This is why it's important to reconsider policies that don't make sense.

[jacquesm]

Agreed, but OP made himself part of that bureaucracy entirely voluntarily. It's as if I show up to a casino and start playing without familiarizing myself with the rules and the environment first. Note that the kernel maintainers are in general getting a lot of crap for doing a very large amount of work and that this sort of post that attacks a particular maintainer by name is really damaging, far more so than if the OP had never submitted their patch in the first place.

[phendrenad2]

Absolutely agree. But remember that this affects all of us, because "with many eyes all bugs are shallow" only works if lots of people show up and contribute.

[camgunz]

IDK this stuff all sounds specious to me. If I envision a world where anyone who contributes Miculas' level of effort into the kernel gets into "kernel contributors", that world seems great to me. Linus wrote a whole new version control system, surely someone over there can figure out how to maintain a list of contributors.

> To ask for credit as a contributor makes it seem as though that was the whole goal

There's nothing, at all, wrong with this.

[jacquesm]

> There's nothing, at all, wrong with this.

I don't know about that. I maintain a small project and I've received exactly one outside contribution, and I made sure to properly credit that. Nobody is going to send me patches in order to gain social standing. But popular open source projects are a different matter and the maintainers there are hip to the fact that people use often minor contributions to increase their standing. Now: the OP clearly went beyond that, and I'm on the same side as another commenter here in that the 'Suggested-by' tag would have been the more appropriate one. But that's hairsplitting to me and if that's worth penning a post like this for, especially one that misrepresents the kernel maintainers words in a meaningful way then all perspective is lost.

[camgunz]

> the maintainers there are hip to the fact that people use often minor contributions to increase their standing

That's a fair concern but I don't think that's what we're talking about here. This isn't someone running around correcting whitespace or documentation to pad their resume. They did a bunch of technical and mailing list research. That kind of effort is promising.

> I'm on the same side as another commenter here in that the 'Suggested-by' tag would have been the more appropriate one

Yeah or maybe "co-author" or whatever (IDK anything about kernel tags). It seems pretty evident to me that Ellerman cleaned up Micunas' original patch using his kernel expertise. I'm not at all calling "plagiarism" or anything like that, but I am calling "collaboration".

> if that's worth penning a post like this for, especially one that misrepresents the kernel maintainers words in a meaningful way then all perspective is lost

I'm not sure what the original private email was so who knows if it's a faithful paraphrase, but I can forgive OP for being miffed and I could also forgive Ellerman for being irritated about being misrepresented. Someone should be the mature person here though, and--call me naive if you want haha--I'd look to the kernel dev for that.

[jacquesm]

For Co-developed-by status though it would require a properly signed off patch which this wasn't. And that's where you run into the issue of this being posted to a security mailing list for all to see: you've essentially started the clock on something that you no longer control and fixing the but takes priority over other niceties.

[camgunz]

Yeah I mean, I want to be respectful of Linux workflows and conventions. I just think it's hard to understand a situation where someone could put this much effort into improving the kernel and not get a contributor credit. Like, by the normal definition of the word it's definitely a contribution: it required a lot of technical skill to do, and he did try to follow kernel conventions when he was made aware of them. It's not really his fault that trying to contribute to Linux is a byzantine process where maybe no one will be at all nice to you.

> And that's where you run into the issue of this being posted to a security mailing list for all to see: you've essentially started the clock on something that you no longer control and fixing the but takes priority over other niceties.

Yeah, but on the other hand it's an obscure architecture and they took a few days to really process it. It also doesn't preclude them crediting him as a co-author.

---

I guess my overarching point is that, while this may be completely reasonable from a kernel dev's point of view--a person super steeped in kernel culture and processes--it's mostly nonsensical to everyone else. This issue is pretty simple. This guy did a bunch of work in good faith, tried to do things right, and some insider basically stole his thunder. That sucks! No amount of like, careful or sympathetic explanations of kernel workflows and semantics is really meaningful in the face of that.

I think the nail in the coffin is that everyone believes this happened right? No one needs to be convinced kernel devs are completely uncaring and insensitive. Maybe that attracts a certain crowd and maybe that's on purpose, or maybe it's just self-fulfilling, but at the very least it doesn't seem very welcoming. Either way, it doesn't bode well for the future.

EDIT: I said they took over a week to really process it but I misremembered, it was just a few days

[jacquesm]

I think that the main sticking point is that the credit for a contribution to the kernel, no matter how small is of sufficient value now that this needs more consideration from the maintainers. And Michael Ellerman actually agrees with that based on his response in the thread. I think a Suggested-by or even a Co-authored-by would be an improvement on the current situation. But the frame of mind of a typical kernel maintainer to me appears to be that they believe you want them to fix the issue, not that the credit matters more to you than the fix.

If I were in the position of the OP the LKML record alone suffices as proof that I contributed a major chunk of work to fixing a bug in the Linux kernel, and if I did feel that the credit was handled wrongly I would have taken that up with the maintainer. And finally, I would have done so right away, not a long time after and in such a disingenuous way.

[mfru]

After how many lines of someone contributing code to the kernel are they considered to be a >kernel contributor<?

How is fixing bugs not a contribution?

[scruple]

This entire attitude around denying attribution is unreal. I see it in industry all of the time, especially now that I'm in gamesdev. People pull out all of the stops to prevent certain people or even certain disciplines from receiving credit for their efforts. It's abysmal.

[peyton]

What’s the incentive here? It seems more likely it just wasn’t a concern to the maintainers. The guy can still call himself a Linux contributor if he wants. He submitted a couple if statements and didn’t get it signed off. Why split hairs over what the commit message says?

[jacquesm]

That is an excellent question. It may well be that even single line drive by patches raise to the bar of being a kernel contributor, it may be that most of the authors of such small patches have historically had a better idea of their place in the greater scheme of things and that what matters is that the bug gets fixed (it's a security issue, after all) rather than that it gets fixed in their way or with their name affixed to the patch.

Fixing bugs is a contribution, and detecting bugs and doing RCA is also a contribution. In this case the OP got credited for the second and the third using the appropriate mechanism. The maintainer could have used another tag to add additional credit, but chose not to as is their right - and custom with such small patches, especially if they need work.

High profile projects such as the Linux kernel suffer from attracting people that just want to be associated with the project, I think OP went considerably beyond that and deserves some credit but does not have an automatic right to a particular kind of credit and if that was his expectation he should have ensured up front that that was the outcome. By posting an incomplete patch for a security issue to the kernel mailing list this was the expected outcome, in fact the maintainer spent considerable time on back-and-forth with the OP.

[DeepSeaTortoise]

> it may be that most of the authors of such small patches have historically had a better idea of their place in the greater scheme of things

Historically, denying those, who went to great lengths for their contributions, even the minor bit of attention they deserved, has led at times to the castle getting torched down.

[jacquesm]

It pays off to have your expectations calibrated before you engage in an activity. To be named a kernel contributor on the basis of this particular patch seems to be a bit excessive (even if it had been properly signed off, which it wasn't), of course you are entirely welcome to disagree with that.

To give some perspective: there are ~30 million lines of code in the kernel and about 5K named contributors, and a much smaller set of maintainers who will accept patches, modify them, discard them, rewrite them and or merge them based on their judgment, which they generally exercise very well.

[peyton]

Agreed the expectations are so far out of line I doubt the maintainers see a problem. If this guy wants to be a kernel contributor he can keep contributing to the kernel.

[hermanradtke]

Flagging someone as a kernel contributor should not be conflated with the magnitude of contributions.

[jacquesm]

The LKML is all the proof the OP needs to show he contributed and precisely in what way. This post is way over the top and even if Michael Ellerman could have handled this better so could the OP.

[bitcharmer]

> That's because it is a tiny fix

And this is how I know you're not a professional programmer, because you naively assume that finding the root cause is zero work. Most of the time it's debugging and testing that takes almost all the time involved in a fix.