Hacker News Reader

I will point out that finding and root causing a bug (and perhaps writing a test) is THE contribution. Very often fixing the bug, once all unknowns have been resolved, is trivial.

Many times a one line fix takes days off debugging and analysis. Seems like this was the case here, since the original bug was open for 6 years.

And indeed, they received the proper accreditation for that. As well as the mailing list entries which are there for all to see.

"Reported-by" reads like: "this person mentioned the problem to us". In this case he did all the heavy lifting which is like 95% of the work. How is reported-by a proper accreditation? I feel like many commenters here never had to debug any complex or subtle, hard-to reproduce bugs. Either that or there are many assholes on this site.

Well, maybe there should be a 'contributed an improperly signed patch with issues' tag that would cover the situation. But in the case of mailing to a security list your general expectations should be to hope that it will be included, and hopefully speedily.

> They did get the credit, just not for the code, and rightly so.

They received credit for reporting the issue, which is a fraction of what they did. They provided the entire solution, full stop. The maintainer only restated it.

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/linuxppc-dev@lists.ozlabs.org/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.

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?

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.

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?

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.

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

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.

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.

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

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.

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.

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

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

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.

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

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.

Well said, 100% agree

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

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.

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.

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.

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.

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

> But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up

I'd suggest not opining on the inner motivations of strangers on the internet. It doesn't add value to this conversation, and your guesses are likely wrong due to missing important context and details.

It's there for everybody to read, as well as in comments here, I'm not guessing at anything. You can't be 'robbed' of something you do not already have.

And that's before we get into misrepresenting the kernel maintainers words in a way that considerably changes their meaning.

Maybe you’re not a native English speaker? “Getting robbed” can also mean not getting something you are justly deserved.

> can also mean not getting something you are justly deserved.

It can, but whether that's the case here or not is debatable and I think what we mostly see here is the OPs unfamiliarity with how LKML deals with tiny patches mailed to the security lists.

> It's there for everybody to read

Yes, it is. His motivation is very clear:

> Around a year and a half ago, I’ve asked my former company for some time to work on an issue that was impacting the debugging capabilities in our project: gdbserver couldn’t debug multithreaded applications running on a PowerPC32 architecture. The connection to the gdbserver was broken and it couldn’t control the debug session anymore.

This is an incredibly uncharitable description of his motivation:

> If the goal is to fix something to be able to put kernel contributor on your resume

So, then the OP should be happy. But that's not what I'm reading, I read accusations about robbery, see words put in people's mouths that are not backed up by the evidence and a patch that misses required bits and pieces to be accredited in the first place.

What they wrote in their blog is without value after changing the nature of the exchange with the kernel maintainer to make them look like a dick when nothing of the sort actually happened. It only proves that you can't believe what is in that article.

He did almost all the work in fixing a problem that had existed unfixed for six years. He figured out what the problem was and fixed it. He did this because it was causing problems at work. When he contributed the fix upstream the maintainer tweaked it a bit and merged it, with a bug report credit. The author did far more than simply report a bug. As he says – the bug was already reported six years ago (and apparently the actual reporter didn’t get credit for that). He figured out what the problem was and fixed it, but he didn’t get credit for that.

His motivation is clear – he fixed the bug because it affected him. The fact that he’s pissed off for not getting credit for that bug fix doesn’t change that.

> If the goal is to fix something to be able to put kernel contributor on your resume

This quite clearly was not his goal. His goal was to fix the bug he was experiencing at work. So why are you saying otherwise?

> So why are you saying otherwise?

Because I read the article and the exchange between the maintainer and the OP.

It smacks of entitlement and shows a complete unfamiliarity with the kernel development process. Maybe that's all there is to this but to claim a kernel developer 'robbed' a first time contributor when in fact what happened is exactly what you'd expect to happen makes me wonder about the OPs motives, especially because he materially misrepresented the interaction between himself and the maintainer to make the maintainer look bad. It looks like the credits were the goal, and if they weren't then what's the fuss about?

> It looks like the credits were the goal, and if they weren't then what's the fuss about?

Because that is how fairness works in the minds of most humans. People can have multiple motivations. I go to work to earn cash, but I'd be unhappy if someone else got credit for the work I did.

However, at least I'd have got paid; if I was doing something out of altruism I'd be a lot more unhappy if I didn't get credit for the work I'd done.

> It smacks of entitlement and shows a complete unfamiliarity with the kernel development process

Even if this were true, it does absolutely nothing to change the fact that his motivation was to fix the bug he was experiencing at work.

> It looks like the credits were the goal, and if they weren't then what's the fuss about?

You are failing to distinguish between the purpose for doing something and something of value. These are two distinct things. The goal was to fix the bug. The credit is of value. The fact that he is upset about not receiving the value he feels he deserves does not alter what the goal was.

It’s straightforward and obvious that he fixed a bug because it was affecting him. Why are you so eager to deny that?

> Even if this were true, it does absolutely nothing to change the fact that his motivation was to fix the bug he was experiencing at work.

Sure, but this blog post was written well after that time, and I do not see the OP aiming to be properly credited in the intermediary. That doesn't mean that a more appropriate tag could have been used, I just wonder about the motivations for the post because it clearly isn't either timely or the best venue to address this, especially not in the way in which it was done.

> You are failing to distinguish between the purpose for doing something and something of value. These are two distinct things. The goal was to fix the bug. The credit is of value. The fact that he is upset about not receiving the value he feels he deserves does not alter what the goal was.

Yes, and that's why I'm totally supportive of having a 'Suggested-by' or even a 'Co-authored-by' tag on this. But I'm also aware of the fact that the LKML record alone serves to document the OPs contribution and that nobody has made any claim to the contrary, he is - to all intents and purposes except for the git-log the contributor of some lines of code. That these were modified by the maintainer is something people normally would not have cared that much about. And maybe that should change, but that's so far been roughly the norm for these kind of fixes.

> It’s straightforward and obvious that he fixed a bug because it was affecting him. Why are you so eager to deny that?

Because of (1) the timing, (2) the misrepresentations in the post, (3) the fact that alternative venues were not sought before making some fairly heavy accusations. It looks to me as though the bug fix may originally have been the reason the work was done and maybe the OP or their employer were happy with it but now, so many months later it seems the OP is more focused on the credit.

"That circle"? You make it sound like an exclusive club for the elite. This isn't supposed to be a popularity contest.

Linus' attitude is very material. Kernel leadership sets the stage for other contributors to do the same, good or bad.

Linus' attitude has nothing to do with it, he wasn't part of this exchange at all. And yes, it's an exclusive club, hence people trying to become a part of it.

Open source software development is not an exclusive club. If you contribute to open source software you are an open source contributor.

Stop gatekeeping.

Security patches are the last place (especially tiny ones) where you want to make a stand for proper attribution of four line patches, the rest got properly credited. Note that the OP misrepresented the nature of the exchange with the kernel maintainer and that puts their motivation about the whole thing in doubt. Nobody got robbed. OP still has contributed code, the LKML lists are proof of that and if you think that in the future every such patch should carry an automatic 'Suggested-by' or 'Coauthored-by' tag then you could propose that. But for now this is the maintainers call and by sending mail to the LKML you play by their rules.

That's not gatekeeping, that's just reality, and yes, kernel maintainers are an in-group whether we like it or not. My take on that is that if I had stuff that gets included that I couldn't care less about the attribution because what they give me is so much more than I'll ever be able to give back. Of course everybody is welcome to their own motivations, but you send unsolicited patches with the hope that they'll be used, if you get credit that's great but then the patch had better be ready to run as is and preferably for something a bit more substantial.

Um, Kernel maintainers are an exclusive club for the elite. Seriously, I'm not even trying to be funny or edgy or anything.

The hierarchy roughly goes: users -> script kiddies -> programmers -> compiler writers -> kernel devs.

If ever I was considering contributing to a FOSS project, this comment and many others like it within this thread has firmly convinced me that it’s not worth the trouble.

That's almost spot on.

I've just barely arrived at the conclusion that I could make a change, offering minor suggestions and changes on projects I care about and then have the read someone degrading a contribution that is still "several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues"

And when you point this extreme ranking out as inappropriate, your comment gets vaporized.

This REALLY bloody hurts

YMMV, but here's what happened with my pull requests.

12 - accepted, sometimes additional changes were required

1 - ignored; this was a trivial change and I wouldn't have submitted it now.

1 - rejected; the maintainer didn't understand my proposed fix and closed the pull request.

1 - rejected; the maintainer disagreed with the proposed change.

This comment is so far off the charts, even I, a pathological lurker, made an account...

Let me see if I get the ranking right:

> But the motivation isn't clean

> The kernel contributors are doing very important work and their standards for inclusion are high.

> security work where the details really matter, so props for identifying the issue

> Perverse incentives are a thing and it is good to be aware of them.

> with a mediocre contribution

>This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues

I wonder where normal people fit into this mental framework.

Contributors with pure thoughts <?> Kernel contributor > Security Contributors > Perverse contributors <?> Mediocre contributors > > People who sneak into OSS projects by fixing minor issues

My comment didn't survive long at all, yet I still recommend giving it some serious thought.

> This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues

As someone just getting started with but a tiny OSS footprint and grade care to not step on anyone's toes, this is a deeply unfair statement.

> If the goal is to fix something to be able to put kernel contributor on your resume with a mediocre contribution in order to achieve yet another goal then that's not a good reason to be credited for the code, especially if it isn't your work that makes it into the kernel

Someone's desire to put "kernel contributor" on their resume is immaterial to the appropriateness of receiving that badge. "Mediocre" is a judgement you're projecting here, but we don't have evidence that the code was mediocre. And even if it was mediocre, most software goes through iterations, the first of which is almost always a mess. If the code he wrote was directly responsible for the code the maintainer wrote, there's a case to be made that credit is still due even if not a single line of the original code made it into the codebase.

"You didn't type the exact line of characters that made it into GitHub so therefore you did not contribute" is a very limited view of the whole series of interactions and investment of human capital that ultimately led to the fix.

> But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up

This is projection again. When you don't receive credit for your work and get upset about it, it does not imply that the only reason you did something was for the recognition. If you get passed up for a promotion at work because a coworker lied and took credit for your work, you're allowed to be pissed about that, and it doesn't mean that you don't deserve a promotion because you worked hard to get a promotion. I don't get the logic here at all.

I agree that if the only reason someone contributes is to play a status game, that can lead to some questionable behaviors. But there's no evidence that this is the case here.

> No, the value of FOSS is the ability to read and modify the source code.

There is no singular attribute that makes up the "value of FOSS". Reading and modifying source code are valuable, but not exclusive to FOSS. The shared value of contributed fixes is also a major benefit of FOSS. FOSS is many things.

> This person did not contribute as of now.

I cannot imagine how you could conclude that the author did not contribute. If your definition of contribution is limited to "lines of text checked into a repo", perhaps you're correct, but this is an extremely limited view and incomplete picture of the nature of open source contribution.

The bug was around for many years. Would the code that did make it into the kernel have been written in the same timeframe if the author had not submitted their own solution?

There could have been many very good reasons not to include the author's code, and I'm not arguing against that. But it seems extremely disingenuous to claim that the author did not contribute quite a bit to this fix.

- the patch was missing a required element if the author wanted to be credited in the first place

- the patch was incomplete

- the patch was mailed to a mailing list that has a different set of priorities than the patch submitter assumed

The author did get credit though and that was for the 98% or so of the work they did. And finally, the LKML will - presumably forever - document his contribution in all its glory.

Anyway, I don't think we're going to see eye to eye on this one, in my experience nothing out of the ordinary happened here. Maybe that's wrong and it needs to be addressed but I would have picked a different hill for that battle.

I was primarily reacting to your assertions that the author doesn’t deserve recognition due to intrinsic motivations and the direct claim that they have as of yet not contributed.

What you’ve listed here are procedural issues that are easily corrected and have no bearing on whether or not contribution actually occurred, and no relation to those broader claims.

Zooming out a bit, maybe what you’re describing is indeed the status quo, and what the author described is a perfectly normal experience. If so, then the author’s piece should be seen as shining a light on kafkaesque bureaucratic bullshit that threatens the spirit of FOSS and thus FOSS itself.

Maybe “kernel contributor” needs to be better defined, and maybe it requires more than one contribution. Maybe there needs to be something more than “reported by” but less than “kernel contributor”.

But again, at no point is it fair to claim that the author did not contribute.

> I don't think we're going to see eye to eye on this one, in my experience nothing out of the ordinary happened here

Frankly, you’re shifting the goalposts so this isn't about seeing eye to eye. “Ordinary” is quite often very problematic, and each person is free to choose their own battles. You don’t have to agree that this was the right hill, but that is unrelated to a reasonable definition of “contribution”, and irrelevant to author’s choice to make some noise about their own personal experience.

Noise is a first step towards improving a situation. Change has to start somewhere. And FOSS maintainers need to be aware of the harm they bring to the projects they’ve been entrusted to steward when they forget about the human factors involved.

> And FOSS maintainers need to be aware of the harm they bring to the projects they’ve been entrusted to steward when they forget about the human factors involved.

All I see is that no good deed goes unpunished.

Or maybe good deeds are good deeds, and bad behavior is bad behavior.

Maintainers deserve gratitude, empathy, and respect. Most of them are holding the line against shitty contributions and shoddy code, and that’s a good thing. The good they do doesn’t absolve them of problematic behavior.

I'll settle for 'perceived problematic behavior' and suggest you read the actual interchange between the OP and the kernel maintainer. Because it paints a completely different picture.

I did read the exchange, and there is problematic behavior all around.

The author did themselves a disservice with their disingenuous paraphrasing. The lack of attribution remains a problem however, and is not justified by the author’s misrepresentation; just as the author’s behavior is not justified by the lack of attribution.

OP could have maintained the moral high ground but didn’t, and that’s a bummer, because now this is an “everyone sucks here” situation.

Attribution remains important.

That's fair. And Michael Ellerman actually agrees that he could have handled this better, I think OP should have just worked on this in private exchange rather than to make a public attack.

I think that given the status of the project there should be a change to the guidelines to ensure that even the smallest contributions get properly credited, but to make sure that then isn't gamed you'd need to somehow get out of the binary 'I'm a contributor' vs 'I've been contributing for years' situation by adding yet another metric or the inflation of the term 'kernel contributor' will be such that some people who do contribute on a regular basis will feel that their status is diminished.

Project governance is complex. I'm very mindful of the reason (see the drama around PEP 572) why GvR quit the status of head of the Python project, being a project maintainer is a very tough spot to be in because every action you perform is potentially going to be under the magnifying glass and all the good you do is forgotten five minutes later.