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

If this is what the maintainer usually does then the maintainer is a wanker. If they leave the project, the project won't be losing a good person.

I don't think suggesting the current maintainers of the Linux kernel taking a hike is a very productive angle.

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.

Do all the maintainers take someone else's code, make minimal changes (in this case changed 1 line from an #ifdef to if (1==1) or if (1==0) depending on the state of a compile time define) and put their name on it? Then, yes, if they leave the project won't be losing good people.

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.

You can find it here:

https://www.kernel.org/doc/html/v4.17/process/submitting-pat...

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.

> If the kernel maintainers feel the ritual wasn't followed, then they can reject the patch

That's exactly what they did.

What a strange definition of rejected.

Keeping 97% of the patch and changing 3% of the patch isn't what anyone would considered rejection.

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:

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

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.

Are you ready to take his place?

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

You can read the LKML mailing list page for submitting patches:

https://www.kernel.org/doc/html/v4.17/process/submitting-pat...

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.

You are way off base here. Notably you’re not a kernel maintainer (at least I sure hope not) and you don’t speak for them. Furthermore I have no idea what you mean by “unsolicited patch”. The whole project solicits patches from anybody and everybody by having open issue trackers and source trees and mailing lists. Who the fuck are you to act like an entitled gatekeeper and disregard Ariel’s work just because he wasn’t familiar with needing a signed off by line. Maybe Ariel was just preliminarily submitting the patch for discussion and was planning ti address comments and sign off on the patch once they confirmed with a maintainer that everything looked good?

> To me there's a difference between having a commit bit ("kernel contributor status") and having a contribution that was accepted into the kernel.

Who do you think has the commit bit on the Linux repo? Hint: kernel contributors don't.

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.

Yes, it should have been under "Co-developed-by".

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.

Tell us, what "development" did Michael do that warranted him getting credit, and the OP not?

Kazinator did a pretty good job at that, besides: Michael is not taking any credit, LKML is there for all to read.

https://news.ycombinator.com/item?id=37675544

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

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.