Note that the degree to which this has blown up is disproportional and that besides the fact that Michael Ellerman could have handled this more gracefully the OP did not seek to resolve this out of band, misrepresented the interaction and ignored an olive branch that would have given him exactly what he wanted.
The bit where I am in strict disagreement with how Michael Ellerman handled this is actually the reverse of what happened: if the original patch wasn't properly signed off on and the OP was responsive they actually put themselves at risk by re-using the code without proper attribution. This - and that's speculative - probably was because the code identified the essence of the fix but introduced a couple of new problems and because it was so small he may have felt that fixing it and adding a 'Reported-by' tag plus the LKML archive would be sufficient cover for that. But from a strict reading of the LKML guidelines that was the wrong thing to do.
And the LKML guidelines themselves should be made clearer with respect to how the various levels of contribution are dealt with because that seems to matter a lot to some people and they need to spell out more clearly that submitting a patch may result in your code ending up in the kernel with LKML as the only visible proof that this is the case. Because the OP may not realize it but that is the essential part: that their submission to LKML ended with a bug in the Linux kernel fixed and there is ample proof to document that and I'm pretty sure that nobody would claim otherwise.
This seems like a very cynical view of what happened here, and completely unfounded.
Obviously these big open-source projects need gatekeepers, but if the gatekeepers often make aspiring contributors feel violated and humiliated rather than offering feedback to get their initial contributions across the finish line, general interest and enthusiasm for contributing are going to dry up. Maybe that's by design, but it doesn't feel sustainable in the long term.
A lot of contributors are going to feel like this if their patch doesn't get accepted immediately and the maintainer in this case was extremely respectful even though the offered patch had multiple major issues. Contributors shouldn't feel entitled to free tutoring.
Seems debatable and debated, reading through the rest of this thread.
Regardless, I'll reiterate my point more straightforwardly: it's the maintainers' prerogative to treat aspiring contributors however they like, but actions have consequences, and some of those consequences may be deleterious to a project's health.
Most of the people commenting in this thread haven't looked at the code and anyone saying the two patches are equivalent can be safely ignored. Out of the issues kazinator pointed out, 1 and 2 are definitely major issues and 3 is debatable although it is definitely suboptimal.
> some of those consequences may be deleterious to a project's health
Of course, but I think it might not be in the way the "everyone can be a valued contributor" crowd thinks.
Of course! Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay, if not those whose merit has already been proven?
This is unironically a very serious problem and why most of the best open source projects are basically corporate FAANG projects that are really only open source for optics.
Talking about utilitarian consequences, Linus had been way worse and while I fully agree from a moral perspective that his most extreme behaviors were bad, from a purely utilitarian perspective that didn't prevent Linux from being one of the most successful OSS projects out there.
Isn't this a little bit disingenuous? Do you really think the author of OP's blog post is upset simply because a Linux kernel maintainer has far more domain expertise than him and is in principle capable of writing a "better" patch?
That would be pretty irrational, I agree!
It would be pretty bad if he said that, but he never did.
Ellerman's actual words were "I wanted to fix it differently", so while I don't think Miculas' paraphrasing was entirely appropriate (why paraphrase at all?), I also don't think it was a misrepresentation of what Ellerman actually said.
It is not unfounded at all. The author clearly stated the reason they wanted their commit to be accepted was should they could be contributor.
I think it would be odd to disbelieve the author.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
Speaking of pointing the above out, why is this comment flagged? Is this considered a personal attack too? https://news.ycombinator.com/item?id=37677835
---
You can see from my other comments in this thread that I prefer to engage respectfully with other commenters, even ones I disagree with, and I believe my total commenting history going back to 2016 will reflect that I do in fact take the intended spirit of the site to heart. But if speaking forthrightly to a bad faith and/or willfully ignorant interlocutor like this user drags me down to their level in your view, you ought to ban me right now. Thanks.
If you find yourself inspecting someone else's comments or behavior for how much bad faith you perceive, or what they couldn't be bothered to do, or anything of the "who said what" variety, you've already fallen off the path of curiosity* and this is a clear sign that you should refrain from posting. That's not a criticism btw! it happens to all of us and it takes work and practice to avoid it. But it's work we all have to do as a community, if HN is to last for its intended purpose. (Btw that's also the answer to why 37677835 was flagged - it wasn't a personal attack but it was a step off the garden path and into the weeds.)
When a commenter uses phrases like "bad faith" or "willfully ignorant" or "down to their level' about another commenter, it's usually a sign that they're too activated by a conversation to really practice this principle (from https://news.ycombinator.com/newsguidelines.html): "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." That's another sign that it would be good to refrain from posting until you no longer feel that way. Why? because first of all, you (I don't mean you personally, but all of us) are not functioning in the range of curiosity when you feel that way—it's physiologically impossible; and second, if you reply with what you call "speaking forthrightly" in that moment, you're quite likely to post things that land with the other commenter, and also the general reader, as attacks.
* https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
Semantics aside, I understand from experience how difficult it is to moderate situations like this, but as a user-privileged participant in any discussion I reserve the right to defend myself (e.g.) when somebody rolls out some half-baked strawman and then accuses me of going off topic. In this case I find it particularly ironic that in a thread full of completely baseless character attacks against Miculas, the author of the linked article (e.g. he just wants credit so he can put it on his resume), I'm the one who gets threatened with a ban for questioning that narrative and not then meekly rolling over for the ensuing tide of bullshit. If you want to see a real, unequivocal, totally one-sided personal attack, you need look no further than the original comment I replied to^[1], and you can't throw a stone from there without hitting another one. I note that those comments remain largely unflagged, which is not a surprise given how acutely vulnerable users of platforms like HN are to the bandwagon effect and similar biases.
My behavior in this regard is not going to change, but my experience in this thread is certainly raising some questions.
In the context of moderating an internet forum, we have to go by effects, not intent: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que..., for a number of reasons: (1) intent isn't observable or generally predictable; (2) effects are both observable and generally predictable; and (3) it's effects which ruin threads.
Everyone always feels like they're the one being singled out and treated unfairly—this isn't a reliable feeling, just a universal bias. If other comments broke the site guidelines as badly as you did, and the mods didn't say anything, that's only because we didn't see them.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
To which you state
> This was not a personal attack, it was a statement of fact.
It's a matter of opinion, not fact.
The lesson here, is always remember context. The point at which you start your input is surrounded with the context of before it. So if you were closer to the start the context of the previous strawman attempts wouldn't have been in play.
That could be, but on the other hand, the Linux kernel is more than 30 years old and is on its 6th version...
One might also consider the rarity of maintainers who can write high quality code and donate large amounts of time. To find and retain someone like that one might also be required to allow them to be curt with random people on the internet from time to time. I can see how drive by contributions could get old fast from their point of view.
Indeed, and while we're speaking in broad generalities, surely no strategy that worked to launch a project from tiny seed to maturity and market saturation has ever then failed to keep it relevant in the long term...
> I can see how drive by contributions could get old fast from their point of view.
Indeed. But (again addressing generalities) my issue here is that the contribution in question doesn't read as "drive by" to me.
If the rate of submissions falls then it certainly makes sense to adjust. Until then, don't fix what isn't broken.
This is a bit of a moot point, though, since I don't think it's very common for Linux kernel maintainers to behave this way. Correct me if I'm wrong.
Part of the job of a maintainer is to curate and foster input so the project has a robust community in the future.
The maintainer in this case did a miserable job of that.
Exactly! If you treat new contributors as crap because you are overworked, you will push away potential long-term collaborators who could share the load thus ensuring you will be working alone far into the future. This is a failure state and if I had a manager doing that to those he was managing, he wouldn't be a manager for long.
In a company where people are expected to stay around for a while, it may make sense to invest time to bring juniors up to speed. But I wonder whether that's true for OSS projects in general. A person randomly shows up to report and attempt fix a bug in an "obscure"(?) architecture -- this is not a junior who just joined the team, and they have no commitment to stick around to do more contributions.
In this case, from a utilitarian perspective, it doesn't seem obvious the maintainer should spend the extra time coaching.
This might be a minority view here, but TBH I don't think anyone should be obliged to go out of their way to spend extra time and effort to avoid offending a random person on the Internet.
1. Please don't drop cases from your #if CONFIG_PPC32 blocks that are handled on 64 bit. You can use if (IS_ENABLED(CONFIG_PPC32)) instead of #ifdef so the only difference is in the array access.
2. Please remove the FPRINDEX macro; as you note in your commit message, we can assume TS_FPRWIDTH is 1.
The maintainer also wrote a long and detailed commit message in his own version of the patch; he had time to explain things.
In this exact situation, I would possibly have made the code adjustments myself and written "patch provided by Ariel Miculas". Then send an e-mail saying that I made a few minor tweaks to your patch, here is what it looks like.
"patch provided by" tells the truth: that person provided a working patch. It doesn't say that the patch they provided is precisely this one.
This is not some rubberstamp formality, it is an actual declaration of authorship and shields the kernel maintainers from possible claims of copyright infringement.
This is always the case for a senior developer dealing with a junior developer. Basically your argument is that junior developers shouldn't try to contribute and if they do, they will just be rejected out of hand if they make any mistakes. Okay.
> But I wonder whether that's true for OSS projects in general. A person randomly shows up to report and attempt fix a bug in an "obscure"(?) architecture -- this is not a junior who just joined the team, and they have no commitment to stick around to do more contributions.
If you treat people like crap, they won't stick around. So it is a bit of a self-fulfilling prophecy.
I think that great OSS leaders are few and far between. One that I can think of that I've worked closely with for a decade is mrdoob of Three.js. Humility, openness, focus and good people skills. I cannot approach his skill set here, and in part that is why I respect it so much. He achieves a lot and there are hundreds of contributors to Three.js of all different skill levels. And he definitely is not going around rewriting simple PRs just because he can and instead he and others are coaching and encouraging the community. This is why Three.js thrives.
I think this particular OSS developer isn't leader and is more of an individual contributor type who doesn't collaborate well. That is okay. It is unfortunate that his behavior is reflecting poorly on the Linux project, but that is who he is.
I don't think that's as wrong as it sounds. There are projects and codebases that are more or less "done" (and heading towards obsolescence) and aren't worth it to expend resources for juniors to learn how to work on them.
It's usually much more rewarding to have junior developers try to implement something "new" instead of fixing obscure bugs on a stable codebase. There's much more leeway for mistakes in new features, there is less/no learning curve to grok the intricacies of the existing code, and fewer surprising edge cases that the juniors would inevitably miss because they haven't been stung by it 10 years ago.
As I mentioned, it's up to the projects themselves to decide how much they want to expend extra resources in bringing up potential new contributors. As with most things in software engineering, it's a trade off.
And yes, the OP feeling angry with the way the kernel maintainer handled this issue could be said to be a trade off as well. I think the only thing that's unfair about this discussion is that you and maybe a hundred others are making claims about the kernel maintainer ("isn't leader", "behavior reflecting poorly on the Linux project", "treat people like crap") for allegedly misattributing credit for a less than 20 line patch.
Imagine a minor mistake you made 1.5 years ago making the front page of HN and hundreds of people slinging insults at you. I wonder how that feels. Quoting from you:
> If you treat people like crap, they won't stick around.
We can also revert this and say that great contributors are "few and far between".
Collaboration, patience, and empathy is a two-way street. Could the maintainer have done better? I guess; I would have done things a bit different. Then again, maybe their dog died that morning and they were in a foul mood? I'm not joking: people aren't perfect, they have good and bad days for all sorts of reasons, etc. Everyone makes a mistake now and again.
But whatever this maintainer could have done better, this blog post also isn't a good look: sour grapes a year and a half later and making a big deal out of what is really a singular minor personal conflict (and with some misrepresentations to boot). Now, maybe the author's dog died this morning, so I'm not going to attach any far-fetched conclusions about this person, or about Cisco, because again, everyone has bad days and no one is perfect.
Making a big deal out of any mistake or conflict is also toxic, as is making rather strong conclusions about a person based on a single event.
You are correct, I definitely would not have written that blog post either.
> Making a big deal out of any mistake or conflict is also toxic, as is making rather strong conclusions about a person based on a single event.
I believe what you are describing is formally called the Central Attribution Error (CAE.) https://ethicsunwrapped.utexas.edu/glossary/fundamental-attr...
You are right, I should edit my original comment to remove my speculations that are probably based on CAE but it is now locked for editing.
He apparently had six years (since bug was reported) to do it. I think he surely could spend some time.
Everyone involved in this story, both the original author, the second person who authored the patch, and the maintainer who reviewed it, are on the mailing list for that obscure architecture. It's obvious that they all care about it. Its "obscurity" in your eyes is irrelevant.
>In this case, from a utilitarian perspective, it doesn't seem obvious the maintainer should spend the extra time coaching.
I was replying to a specific comment suggesting that the maintainer should do a code review, give comments and ask for an update to the patch, instead of rewriting the patch. Quoting my words out of context isn't helpful here.
When that is done, often the fix is simple, and the author's patch sometimes just ... isn't that great, often for entirely understandable reasons, so it's easier to just fix it myself "from scratch".
So whose patch is it then? In some cases the patch was useful and I'm "inspired" by it, in other cases I'm not. I tend to err on the side of caution, but I've definitely merged my share of patches where the Author field was, IMHO, kind of a lie.
As for code review: it's really time-consuming. And while a few "minor bug fixers" of today become "hard-core contributors" or tomorrow, realistically, most people show up to fix one bug and are never seen again. That's perfectly fine! But it does mean that "teaching" everyone who shows up quickly become an enormous time sink. There's a bit of a trade-off to be made here.
A. U. Thor can point to that 10 years later and say he or she fixed that; nobody cares if the maintainer changed a few things.
That happens constantly for new contributors to a project and it is the proper way to do things - it teaches people and brings them up to speed. If you just redo their work, you are discouraging them from contributing while also not allowing for a teachable moment.