3 ms·
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
by wang_li 3y ago
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.
- jacquesm 3y ago> If the kernel maintainers feel the ritual wasn't followed, then they can reject the patch That's exactly what they did.
- wang_li 3y agoWhat a strange definition of rejected. Keeping 97% of the patch and changing 3% of the patch isn't what anyone would considered rejection.
- afr0ck 3y agoSeeiously, 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.
- foldr 3y agoAs 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/linuxppc-dev@lists.ozlabs.org/msg221990.html https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/m...
- afr0ck 3y agoAgain 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".
- foldr 3y agoIt 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.
- afr0ck 3y agoIn 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.