It would have been more appropriate to just give credit to this guy even without accepting his full patch.
Clearly no one was fixing this security issue unless he found it and submitted a fix.
It’s unethical to not give credit, in particular if Michael read his patch, changed some stylistic things, and submitted it himself. I’m surprised everyone thinks the maintainer is in the right here.
If someone scooped up your work and took full credit for it, despite it being a collaboration (and even if miculas code was absolute garbage it was still a collaboration), that wouldn’t feel right, and you wouldn’t want to work with them again.
I used to think it was fine to take someone else's contribution and then create a total rewrite of it in my own branch and merge that. Or to go into someone's PR and push a rewrite into a new commit on Github. At least in the latter case there'll still be a contributor credit (`Co-Authored-By`), but someone had to do the same with me for me to realise that it kinda sucked and really soured the experience of being a contributor. In my case, it was that someone 'forked' my project by dumping the code into their own repo without any of the commit history.
As you say, even if the code was shite, the refactored fix that got merged in would never have existed without it. "I like my version better," feels pretty dismissive and regardless of any other fact I can see how anyone would feel a bit miffed about that after they put the work in.
Edit: the reply linking to the actual response from the maintainer invalidates my last sentence.
This is much more reasonable than the "paraphrased" reply in the blog post.
I think it's somewhat dishonest that the blog author used the quotation feature in his blog post, but instead of including a quote he made up his own response as if the kernel maintainer said it. I barely noticed this parenthetical above the gigantic block quote:
> He said (paraphrasing):
Anyone reading the blog post too fast would assume the kernel maintainer actually said those dismissive words in the gigantic block quote.
Yeah, and I might have felt a bit “blind” if it were not for you guys also having the same experience: I did not see that parenthetical at all, probably both on account of the linebreak right before it and the (as you say) huge blockquote.
I would hope the author of the post corrects this, "I wanted to fix it differently" is not even close to "I like my version better."
It's still a bit crap to not get proper credit, but it's not fair to put words into someone else's mouth either. The author isn't paraphrasing, he's sharing the story he's told himself after being upset.
I have this done to me a lot and honestly don’t feel a thing. People don’t really care about other people’s coding styles anyway (except they all suck); the thing got done, everyone got credit. I guess everyone feels differently.
Agreed. The maintainer can insist on writing the code that makes it into the kernel for quality purposes - that makes sense. But here the article author is a co-author of that patch.
In academic publishing, this is analogous to sending a pre-print to someone, and that person then publishing on that topic listing you in acknowledgments rather than as a co-author. I get that the point here isn't publishing, it's kernel development, but authorship is still quite important for a professional C.V.
Agreed. I see the job of an experienced maintainer as a facilitator who should bend over backward to help other people's contributions land cleanly. The help often involves feedback on style and architecture consistency, but a sign of a great maintainer is someone who credits others, and mostly stays behind the curtain making sure everything goes smoothly.
The first few times I submitted suggested patches to the Linux kernel (before semi-automated submissions through the LKML were possible), I had a dialog with the maintainer (Ted Tso in this case). Once he was satisfied with the correctness of my work, he incorporated the patch and all was good. I never asked for, nor received any credit. I was solely interested in improving the kernel and not interested in getting my name in there. (My name ended up in the contributors list anyway for something else a few years later, but I never cared one way or the other.)
I agree, it obscures all the heavy lifting debugging and validating and certifying with strong confidence the fix works and continues to work, the guy even tested it on newer kernel releases. Someone who exudes that much perseverance should be welcomed with open arms. These are the kind of go getter get stuff done type of individuals every company longs for.
The thing non-kernel people (including this guy) don't seem to understand is that the debugging and investigation is much more valuable than the actual code fix. The author of the article and commenters here seem overfocused on the actual patch. But the valuable and hard part was identifying the issue. Reported-by gives credit for that.
(Sure, in the same situation I would prefer to also be credited with authorship too. But I get it.)
Reported-by should go to the person who reported the issue 6 years ago. Finding the issue (again), investigating, debugging, fixing and testing that fix sounds more like a hypothetical "Fixed-by", or co-authorship, depending on how similar the final patches really are.
Authoring the patch is often trivial once the debugging is done. Describing the debugging as just reporting is underselling it.
That's fair, but before you know it you're going to have a whole taxonomy of different kinds of contributions and there simply isn't one for 'x did RCA' and the fact that the original patch wasn't properly signed off as mentioned in the exchange with the kernel maintainer may have been all that stood between that and another level of accreditation. Which by the way wasn't responded to by the OP as far as I can see, even though the maintainer clearly mentioned it and the LKML list spells out that that is a requirement for accreditation.
yah, this is a sticky point. This is one of those scenarios where I put the onus on the person more familiar with the process to inform others for these sort of nuances. Its one of those information asymmetry / familiarity problems. Maybe both were not well versed in the concept of coauthorship though to be fair and it didn't occur to either of them not knowing what they didn't know.
I suspect the maintainer never properly realized how much Co-authorship or authorship of the patch meant to the contributor (given that this was their first contribution), and that was probably informed by the size of the patch, the fact that the OP used their corporate email address and the fact that the patch was very small, required work wasn't properly formatted for immediate inclusion.
One thing I've learned from this thread is that as maintainer of a FOSS package, especially a popular one you are always going to get yelled at (to the point that people will make up reasons and put words in your mouth for yelling at you), no matter what you do. People are literally calling for the maintainer to leave.
My 'fixation' is that if you write a 1000 word angry blogpost attacking a kernel maintainer that you weren't properly credited that you could have at least submitted your patch properly formed. You seem to think that a sign-off is a formality, but it really isn't: it's to shield the kernel maintainers from copyright lawsuits by parties that surreptitiously include copyrighted code. It is a very important item on the checklist for a maintainer. You need to personally certify that you are able to make this particular contribution. See the LKML guideline for submitting patches that I've already linked to twice now.
Having that present would have likely increased the chances of this thing never happening in the first place by a significant factor. Almost every large open source project has their own quirky bits like that and as a newcomer you should at least read the documentation on how to contribute if you want to contribute, especially if that documentation is readily available and meticulously kept up to date.
Note that LKMS treats patches typically as proposals and not as must include verbatim or ignore and that by engaging the Linux kernel security mailing list a whole pile of mechanisms kicks in that remove options to play nice with newbie submitters and to help coach them through how to reach the state of the patch that would have been expected the first time around.
OP is aiming a pretty heavy handed attack on a kernel maintainer (a thankless job on the best of days), does so by misrepresenting their interaction in ways that matter and on top of that couldn't be bothered to read the docs.
I follow your point about the OP maybe not understanding some context and well it's just a hard lesson learned.
I don't follow your fixation on sign-off. I am familiar with the guidelines. Like I said, sign-off is clerical. Yes it's obviously important, but it's still clerical. Nothing you've said changes that.
I agree there's obviously a middle ground here where both the maintainer was acting in the best interest of the community to get a security fix integrated and where the first-time contributor was perhaps miss-attributed in the commotion and feels slighted but also can learn a lesson. I'm not one of those out there calling for a witch hunt to cancel the maintainer (honestly I don't know where to those people are, but I'll take your word that you've encountered a few of them).
Still, your fixation on "well Ariel didn't sign off on the commit so all's fair" is pretty dismissive of the work Ariel did to get to the patch. The bug was acknowledged and outstanding. This obviously wasn't something massively problematic or the original bug would have been fixed when it was reported (I guess maybe it was misunderstood and it really was serious, but I don't get that vibe), so I don't think we're dealing with a case of urgency trumping all human decency.
At the end of the day, Ariel is a contributor. No not someone who has privileged commit access to the software, but a contributor to the project nonetheless, whether a maintainer copy-pasted the work or not. And hopefully someone who will continue to contribute in the future. I hope Ariel can come to see it that way whether the maintainer tries to make things right, or even just apologize for the confusion, or not.
I don't read Ariel sharing his experience as an attack. I read it in his words as:
> Well, I certainly didn’t feel inspired to get involved with the kernel community again. On the contrary, I felt belittled and angry that my work wasn’t properly recognized.
> My first contribution to the kernel was a really frustrating and discouraging experience, dealing with people who do not think it’s important to get proper recognition for your work.
I, at least, hold the "lkml bureaucracy" to higher standards.
He choose explicitly to bring the Linux security mailing list into this and that changed the playbook considerably. That changes the situation from one where you can take your time to coach the new person to one where speed is of the essence.
Whatever work Ariel has done has been grossly negated by this attack piece, besides the fact that it omits and/or materially alters the nature of the interaction. At no point did the maintainer leave any doubt as to their intentions, nor was anything that happened unexpected. If you start off your career as a contributor to the Linux kernel by mailing the security mailing list then that requires you to do your homework because otherwise things will be out of your hands. If that was the OPs intention he would have done better to leave the security mailing list out of it and first strike up a conversation with the maintainer about what the best way to start contributing is (there are guides as well, but since he clearly wanted to target this particular subsystem that would have been a valid approach in my opinion).
It's an attack to me because (1) it mentions an exchange that names individuals and (2) it does so using some very expensive words ('robbery'). That's not the kind of accusation that you make lightly and in this case I think it is vastly misrepresenting what actually happened. You only have to read the responses in this thread to OPs misrepresented account to realize how much effect such a thing can have.
What happened is that someone new chose a wrong and ultimately broken way to submit a patch to LKML and that the maintainers did their best to get maximum mileage out of it without wasting time on formalities. Note that these are pretty busy people, to put it mildly and by mailing the security list you've just made them that much more busy still (even though, technically the patch was an improvement it still required work that then ended up becoming high priority).
As for Ariel being a contributor: according to LKML he submitted a proposed patch that needed work, wasn't properly signed off and according to the git commit log he created a report. That's the extent of it, and that's fairly accurate given the standards for these things.
If you want to argue that those standards need work then you may well have a point. But within the current framework this all was 'business as usual' and totally expected.
I'm not arguing with any established contribution process. I'm arguing with your interpretation of this entire issue because it's plain and simply uncharitable and wrong and furthermore doesn't come from any position of authority. You've littered the entire comments section with your snooty attitude and it really doesn't progress the dialog one bit. More importantly, it's not how a community should treat contributors which is why I'm even commenting in the first place. I can handle internet divas being pathetic asshats on HN when it's only hurts themselves. I can't handle the same at the expense of a well-meaning contributor who put in hard work to fix an issue that makes the kernel better for everyone and especially where it involves spreading blatant misinformation about how the kernel community supposedly is allowed to treat people, and takes liberties with IP law.
I even tried to reach a middle ground understanding and you've doubled down asserting that there's no world in which the author's lived experience can be valid because he didn't initially add a signed-off-by line. If you actually read the post, the author spends most of the time describing the issue and the fix. He takes maybe 5 sentences to explain how he didn't feel like his contribution was accepted in a considerate manner and it's discouraged him from making further contributions. It's not some grand 1000 work attack and if anybody has the thick skin to withstand one of those it's the goliath of the LKML.
Anyway, the author pretty explicitly states that he did go back and forth with the maintainer privately and provided a fixed up patch which addressed feedback he'd received on the first patch (presumably with a signed-off-by line, now) and the maintainer still didn't want to give credit. You've conveniently ignored this part of the narrative entirely. This really discredits your whole "it was a quick security list issue and wasn't even formatted properly lol this guy obviously deserves no respect for engaging the security list and generally being a noob" angle.
Everything that we know points to the contributor trying to act responsibly by engaging the security list first since they didn't know the security impact of a possibly major security issue (overwriting the stack of a traced process). I completely fail to understand your logic whereby doing so means the OP obviously fucked up and deserves to have his contribution belittled and stolen and that's just life on the LKML... seriously I think it's time you just admit you're in the wrong here and stop shit posting.
We've already been through the whole "you shouldn't need to have thick skin and tolerate insults and disrespect to contribute to the linux kernel" as a community. Linus even took a leave of absence over this shit. Your stance that this stuff is acceptable and par for the course is no longer the status quo. Grow up.
Not adding much to the conversation with my comment here, but I'd like to thank you for calling jaques out on their attitude.
I've been trying to browse this thread and before I started checking usernames I got the the impression that there's a whole world of maintainers who think it's acceptable to be disrespectful to people spending a lot of time and effort on trying to contribute.
It turns out it's just a few (very prolific) people creating a lot of negative noise across the thread. Thank you for stepping up.
FWIW, that "Signed-off" gate isn't as solid a shield as one might want.
If someone put the work in to identify a bug, contributed a fix, and that fix wasn't accepted but another fix inspired by the previous fix was accepted... That could be plagarism.
Burden of proof is on the plaintiff to prove the fix was inspired by the RCA and proposed fix, of course, but this isn't exactly a clean-room work and kernel maintainers should probably be careful about taking ideas without signoff on the lead-in side too. There's a reason Marvel et. al. in the publishing world can't accept new character concepts.
The purpose of DCO is to move the guilt of plagiarism etc from the Linux kernel project to the individual contributor who added the Signed-off-by line.
Indeed. What I'm saying is it might not work to remove that guilt if a bug is reported and a solution presented, and then instead of incorporating the solution presented the kernel team (without DCO in hand) fixes the bug using code that looks suspiciously inspired by the provided solution.
This is murky enough that it would have to be decided in the court of law, but it's not cut and dry enough that it would be immediately thrown out of that court of law.
The patch I found was signed off. If it wasn't I fail to see how the maintainer could have legitemately signed off his own patch considering it was modified from or inspired by the original patch.
I did not find that yet. Can I read that anywhere?
My understanding is that if the initial patch was not signed off then the maintainer could not sign off his patch, unless he wanted to take on the liability of certifying that the contributor was indeed allowed to contribute the initial patch under whatever license we are talking about here. That sounds like a legal risk I would not be willing to take.
I see which email thread you mean now. AFAICS OP submitted the patch with a proper sign-off again approximately 6 hours after they were told the sign off was missing. So I don't see how that could have been an issue. The maintainers patch is from more than a week later.
> Yes, and that was one of the reasons the maintainer rewrote it (which wasn't a lot of work since it was a tiny patch anyway).
I don't think a simple rewrite is enough to convincingly solve the described problem. There is a reason "clean room design" exists and considering the maintainer read the original patch first before creating their own there is a good argument that they were at least subconsciously inspired by the original patch and therefore plagiarized. That is how I understand the legal aspects of this, anyway.
Reporting a bug is a lot less credit than debugging and fixing a bug. He did the latter, even if his exact fix didn't end up being the one merged into the repo.
Generally most of the work occurs after a bug is reported, as it did here.
Which is all the more reason to give good credit. I have to justify effort I do on company time to my boss. If I had to put in months of work on company time, that needs to be clear to my boss's boss who may not know anything about programming but signs the check. Such people think writing code is the hard part, so it is easier to justify the costs if I'm given credit for writing code for several months (even though the code itself took a couple hours)
I'm pretty sure most software people do understand that the work leading up to the fix was the most valuable part.
I feel like what some people don't understand is that there are contributions like this all the time, and it is often better to take the submitted code as a proof-of-concept than bring a newcomer up to speed on the maintainers' coding standards.
The author's proposed patch had issues raised in review that were never addressed. I disagree with the characterization that the differences between the two authors' patches were purely cosmetic.
There's no such thing as a "have-debugged-and-contributed-actual-code-to-fix-it:" tag. He didn't write the actual commit that fixed the issue, so he was credited in the commit message instead. That seems fine to me. The fact that they didn't include an entire paragraph detailing the exact nature of his contribution isn't a reason to blow this up into some big community drama with over 500 comments on Hacker News.
Those might be better, but neither is a tag that is used in kernel commits. There is a list of specific tags that are used, and specific conditions on their use. "Reported-by:" was not a wholly arbitrary choice of words by the maintainer.
AFAIK, there are no rules limiting what tags you may use -- you can make up your own if you like. And people have. Here's what the kernel git says right now:
My suggestions are both there (far less often than "Reported-by:", but that's not surprising). I think "Analyzed-by:", "Debugged-by", "Diagnosed-by", "Originally-by:", or "Original-patch-by:" would also have worked.
If you don't filter out the tags with less than 10 uses, there are some fun ones. For example, "You're-my-ding-a-ling-by:" should be used more often. :)
There is Analyzed-by, it's not super common but in the end you can make up whatever *-by you want. You can also say "Thanks to ... for analyzing the issue and suggesting a possible fix".
I think it depends a lot on how much the final patch was based on the one he wrote. There are a few phases of solving an issue:
Identified: They have found an issue and reported it.
Debugged: They found the cause of the issue.
Fixed: They wrote the fix.
It seems that Ariel should be credited for somewhere between Debugged and Fixed. But is only explicitly given credit for the first "tier" of solving the problem. It would have been nice to explain a bit more the work that Ariel put in.
But I agree that I wouldn't expect an inferior (by the maintainer's perspective) patch to be included just to give that credit. But a sentence explaining how Ariel contributed would likely be much appreciated.
Unfortunately the author wasn't comfortable sharing his patch ("this mailing list is private so I cannot link to the original patch I sent"), but a comment now buried deep in the discussion [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 wrote the fix and the maintainer merely edited it to fit the project style.
If that truly is all that was done, how hard would it have been to ask the author to quickly make that change?
IF the patch was only edited for style or other minor issues, then the copyright remains with the original contributor. If the patch was completely rewritten from scratch and is very different then not. (linux does not require copyright attribution)
If the poster wants to get a lawyer he can probably force rewriting git history to give him credit. Is it worth it - probably not.
But the OP has copyright. The LKML archive is there for everybody to see, they wrote a bit of code. That code was then modified and that modified version was entered into the repo under the maintainers name, as it usually goes. And that's because when you mail LKML you play by their rules, which have been made very explicit:
"A Co-Developed-by: states that the patch was also created by another developer along with the original author. This is useful at times when multiple people work on a single patch. Note, this person also needs to have a Signed-off-by: line in the patch as well."
and
"Note, you did not properly sign-off on this commit, so it couldn't be
applied anyway :("
From the exchange between the OP and the kernel maintainer. Which may have been the whole issue.
None of that changes the fact that the original patch is copyright by the author, and it is highly likely the courts will consider the changes style issues which do not change copyright ownership. Unless the kernel maintainer can show he didn't look at the patch, only the description of the issue and then recreated the patch from scratch.
Seriously, this is getting way out of hand: when contributing to a project that has been going for more than a few decades you need to first familiarize yourself with how things are done to set your expectations for the interaction appropriately. The Linux kernel group does a pretty good job and they have their own ways of doing things. It's custom - and polite - to get the lay of the land before yelling 'robbery' when what actually happened is exactly what is supposed to happen: the bug got fixed, you got credited for the report and the maintainer spent some of their - precious - time on getting your proposal - because that is what a patch sent to LKML is - fixed and included.
And that's ignoring for the moment the fact that the interaction wasn't at all like the OP suggested it was.
Going to court about this is a right. It might not be a good idea, it might not be worth it, but it is a right.
> The Linux kernel group does a pretty good job and they have their own ways of doing things
I'm not saying otherwise. However their own ways of doing things appear to be illegal in regard to copyright, and if so they need to change. Yes the maintainer spent time, but it appears like more credit is being claimed by the maintainer than is deserved, credit that should go to the patch submitter. It doesn't matter if this is normal Linux process, it is still wrong and the maintainers should change their process to be morally correct.
Of course I don't know if the interaction was as OP claims or not. I'm not really interested in digging into it more. Unless I'm on a jury I won't (and a jury is not allowed to dig into it - but that is a different discussion)
> However their own ways of doing things appear to be illegal in regard to copyright, and if so they need to change.
I think they're doing things as 'by the book' as possible.
> Of course I don't know if the interaction was as OP claims or not.
Well, he documented it twice and those two accounts differ considerably.
> I'm not really interested in digging into it more. Unless I'm on a jury I won't (and a jury is not allowed to dig into it - but that is a different discussion)
Who will the OP sue?
For what exactly?
In which court?
None of this makes any sense. If you think the possible outcome of submitting an unsolicited small and broken patch to a security mailing list of a major FOSS project is going to result in you taking anybody to court for copyright infringement then it probably is a great idea not to contribute at all, this will save everybody time and grief. Besides that: the OP - as far as I'm concerned - has copyright to their contribution to LKML, note that nobody except for the OP claims that this is not the case.
It's interesting how for instance all of the comments written in this forum are technically copyrighted by their writers. But you don't control them after submitting them because of the way the forum is structured, the jurisdiction that it is run from and the expectations that come with forum comments. LKML patch submissions are like that as well: they come with a whole pile of baked in assumptions that the OP apparently wasn't familiar with. The idea that each and every minor patch author, especially of patches that are broken and that do not contain required elements is going to end up being hand-held through the process of making a proper contribution is ridiculous.
The maintainers work-load is such that the pay-off is that your contribution is looked at at all, better still if it results in a fix (even if it isn't literally yours). And if you want credit then you should at least state that up front so that the maintainer has a chance to work with you out of the spotlight until you're ready to submit your patch publicly.
Threatening to sue on account of something like this is exactly why I would never be the maintainer of a major open source project, life is too short to deal with all the drama and entitlement.
If it were me I wouldn't think it was getting out of hand. Kernel contributions are the kind of thing that goes on your resumé and can land you a dream job. I would look into courts too.
Then please never submit any patches to LKML because the last thing a maintainer needs is a court case from some entitled newbie that can't be bothered to read the documentation and on top of that is so focused on accreditation that they are willing to go nuclear over a teensy contribution.
FWIW a submission to LKML does not come with any kind of guarantees for either accreditation, use, timeliness or consideration. You are making a small gift to the Linux kernel and all of its users and as such you are being thanked. Hopefully you got more value out of the Linux kernel than you contributed on account of the work that others have put in. The LKML record will suffice to prove your claims of copyright but realize that your work does not stand on its own, it is always going to be within a larger context. Try affixing a (C) Worewood to a patch you intend for inclusion and send it to LKML and see how you'll fare.
The fact that this kind of kernel patch is in any way relevant to one's resume is exactly the thing that is getting out of hand. And the author links to his linkedin profile in the footer, and well, the reference to this patch/contribution/whatever is there, unsurprisingly (and it is the only thing there that they cared about enough to expand upon).
> Well, if it was, the maintainer didn't communicate that well/at all:
You're making the mistake of accepting at face value a one-sided account of an issue, and in the process failing to even check what the answer actually was.
I don't have access to the private emails between me and Michael Ellerman anymore because I exchanged emails with him from my work email address. I've switched companies since then so unfortunately I don't have access to that conversation anymore. I do remember he pointed me to another bug that I could fix if I wanted to become a Linux kernel contributor. The first part I was paraphrasing from what I could remember.
Reported by would be appropriate credit if (a) the maintainer did not read Ariel's code or (b) Ariel's code was utter crap, so it was effectively discarded.
"I like my code better" indicates that neither of this happened. So, Ariel deserves (at least partial) credit for fixing, since this was not a "clean room" fix.
"Reported-by" is absolutely not the appropriate level of recognition for Ariel's input. This would be suitable if he just raised the issue with the maintainer along with some context. Instead, he put a lot of work into figuring out the nature of the problem and implementing a fix.
This is very unethical conduct on the maintainer's part.
> This is very unethical conduct on the maintainer's part.
And this is why finding good maintainers for visible FOSS projects is hard.
You know what's unethical conduct? Misrepresenting someone's words in a way that make them look bad.
The maintainer did exactly what they usually do, I see absolutely nothing unexpected here, note that this was an unsolicited patch sent to a security mailing list. And this is typically how those are dealt with. To claim 'unethical conduct' is one small step removed from a formal complaint about the maintainer, and which is exactly the wrong message to send here. Witch hunts like this cause good people to leave FOSS projects. The maintainer could have given more credit but chose not to, that's the rules you play by when sending in unsolicited patches. If you must have credit then you should not contribute in this fashion.
> The maintainer could have given more credit but chose not to, that's the rules you play by when sending in unsolicited patches
Is something like "we may accept your work and choose not to give you credit" actually stated somewhere when you sign up for or submit to that security mailing list?
Because that's certainly not the usual rule for unsolicited work in other contexts.
Absolutely nowhere does it say that accepting your patch will lead to you automatically being given kernel contributor status, and to require that status on the basis of committing a single tiny patch that wasn't properly signed off and required work shows a different set of expectations than one that I would see as reasonable.
To me there's a difference between having a commit bit ("kernel contributor status") and having a contribution that was accepted into the kernel.
Now to look at this patch it looks Michael took the report, debugged, tested, and resolved the issue, when all he actually did is move a single line to outside of a conditional.
> and required work shows a different set of expectations
You're really stretching here, the only "required work" missing was a sign off, which Michael could have given.
In any other environment, this would be plagiarism. And it looks morally poor.
Well, we're going to have to differ on that then. Michael - in my opinion - properly credited the OP for his contribution, he could have done a longer back and forth to coach the OP to present the 'perfect patch' but this is the wrong venue for that.
Besides that the OP misrepresented the interaction to a degree that he loses my sympathy, he makes the maintainer come off like a dick when in fact that wasn't the case at all, the interchange was polite and to the point and exactly in line with what I'd expect from a kernel maintainer.
10–20 good patches is probably the minimum baseline for a contributor. Merging a couple if statements into mainline verbatim is pretty iffy. This guy’s expectations are whack.
I don't think extrapolating "one person who acts badly not being much of a loss" to "all maintainers should leave" is a good interpretation of what was said.
If this person is a wanker they all are, if this person should leave they all should leave. Absolutely nothing happened here that warrants such a response.
You really should familiarize yourself a bit more with how contributions to the kernel work, especially because there is an excellent document that lays out exactly how contributions to the kernel are handled.
No part of that document details out that if you fail to follow their exact ritual then they get to steal your code and include it as their own. In comments all over this thread you go on about OP not following the proper ritual to appease the Greg Kroah-Hartman, for the code not being significant enough, for being unsolicited, for not being exactly as some random maintainer would like it. None of that matters. What matters is that this guy's code is in the kernel, unattributed, with minimal changes. If the kernel maintainers feel the ritual wasn't followed, then they can reject the patch, not steal it.
Seeiously, what are you expecting from Michael? Go back and forth with the newbie until he makes a perfect patch? Sorry, but that's bullshit and clearly a horrible use of a maintainer's time.
Michael did his best by fixing the patch and incorporating into the kernel and properly giving credit to the newbie by using the "Reported-By". The fact that there isn't a proper tag to describe the newbie's case is not Michael's fault. Maybe the kernel should add a "Debugged-and-fix-suggested-by", but I also think this is bullshit.
As noted elsewhere in the thread, there is no fixed set of tags that Michael was limited to choosing from. And he has now acknowledged that the use of Reported-By was incorrect:
Again as I said, maybe "Reported-By" was not the most correct tag, but it still attributes some form of credit to the newbie. I just think that's too much woke culture and self entitlement from the newbie. You just have to work harder and up your skills to match the maintainer's standards before you can be called a kernel hacker. One or two patches, imho, is not enough to be called a kernel hacker, especially when it's only about fixig a bug. I fixed many similar obscure bugs. Writing a precise algorithm for Automatic NUMA balancing is a true kernel challenge for which one deserves to be called a kernel hacker.
When I started contributing to the kernel, it was super painful and I failed multiple times. I got super harsh comments (someone called me "retard. It was fun, I laughed, eventually part of my work gor merged) but I always respected the maintainers and I was eager to better myself and improve my analytical and development skills with an open mind to be as sharp as the senior hackers. I always looked up to them and never thought in the same way the newbie did when my patches got re-written or dismissed. I just considered myself "not good enough" and I felt "I had to work harder and smarter".
It is irrelevant whether or not anyone considers this guy a 'kernel hacker', because all he wanted was proper credit for the work he did, not a shiny gold badge with 'kernel hacker' written on it. There is never any excuse for failing to credit people's work. It seems you agree that he was not properly credited in this instance (and indeed Michael acknowledges this in his apology).
Your second paragraph is the same logic that frats use to defend hazing rituals. (I went through it, so why shouldn't the new guy?)
Introducing the word 'woke' into this discussion can't possibly be a good idea.
In my opinion, it's all market economics that decide how things work. The moment you introduce a complex courting procedure, where maintainers are required to be nice and acknowledge every little detail and guide the newbies through every half-baked contribution, you'll kill the project. That's because what keeps the maintainers and the senior contributing and maintaining is the technical work and not the human work. Most maintainers would rather spend their time exploring, contributing and doing technically useful stuff than making every newbies happy and welcome and teach ing them to be smarter and better developer. Such a project will automatically loose the ultra smart, self-driven people that keeps projects like the Linux kernel relevant for more than 30 years. It's all market economics.
No, it’s simple ethics and nothing more: credit where credit is due.
The maintainer said this guy ‘reported’ the bug when he’d actually diagnosed and fixed it. That was a mistake which the maintainer since apologized for, and the mistake could have been avoided without any additional time and effort on the maintainer’s part simply by using a more appropriate tag.
You are really going off into outer space with this stuff about ‘market economics’ and ‘complex courting rituals’. In my experience, whenever I need to make very complex and wide-ranging arguments to justify my behavior, it usually means that I’m the asshole.
The "Reported-By" must be read in the context of the patch carrying that tag, and not in the context of the blog author's initial issue. The accepted patch has the following title:
> powerpc/32: Fix overread/overwrite of thread_struct via ptrace
Miculas is credited with identifying the low-level issue: ptrace is overwriting thread_struct. To me, that does recognize that Miculas did significant analysis work.
No, because as the exchange between the maintainer and the OP explicitly mentions it wasn't properly signed off on. That's the requirement for that particular tag: that a submission is in principle ready to be applied.
The sticking point here seems to be the DCO, which the “signed off by” thing attests. With that attestation other people who sign-off to the DCO can carry the patch forward (maximum to a pull request against Linus' tree). Without it though you have a broken chain.
But it ain't much of a sticking point. Most of the time it is just an oversight that can be pointed out and corrected. All it takes is for the maintainer to point it out and ask for it and then then the author to do it. (The patch author themselves need to do it or else there wouldn't be a point to the sign-off; forging a sign-off would defeat the purpose.)
Clearly no one was fixing this security issue unless he found it and submitted a fix.
It’s unethical to not give credit, in particular if Michael read his patch, changed some stylistic things, and submitted it himself. I’m surprised everyone thinks the maintainer is in the right here.
If someone scooped up your work and took full credit for it, despite it being a collaboration (and even if miculas code was absolute garbage it was still a collaboration), that wouldn’t feel right, and you wouldn’t want to work with them again.