Somebody is pretty salty for no good reason. The maintainers own patch is nicer code than the suggested patch - and the change is small enough that there just isn’t anything available to guide the reporter to a better solution without wasting everyone’s time.
I’d probably have added a thanks for debugging effort into the commit message myself - but “please accept my patch because I want to have code in the kernel” is a very stupid thing to say, and the maintainer offering a suitable problem to fix is more than I’d have done in that situation.
As someone who had a mildly unpleasant interaction with kernel folks, I can totally understand the issue.
This is one of the very few open source projects I had the feeling they don’t appreciate new contributers. There is no on boarding material available and picking the wrong subproject mailing list results in being ignored. You have to spend days without any possibility of help and if your are lucky you get mentioned as a reporter. For the next issue you start from square one as there was no guidance, so you could only learn the bare minimum.
So yeah, his patch may be underwhelming. But the help and credit he got for days or weeks of unpaid work was basically nothing. You may be okay with spending days and only getting credits for the bug report, but I suspect many aren’t and will not contribute again after such an experience. And post like this try to point out the issue they have and why many people won’t contribute to the kernel ever again.
So yeah, his patch may be underwhelming. But the help and credit he got for days or weeks of unpaid work was basically nothing. You may be okay with spending days and only getting credits for the bug report, but I suspect many aren’t and will not contribute again after such an experience.
Especially in this particular case the effort is in debugging the problem, not doing the actual fix - which is the bug report, where he got credited for. lkml is not the place for “how I debugged this problem” - that’d be what goes into his blog. And if you look around you’ll see a lot of “how I helped solving this problem” kind of blog posts.
This change is so simple that guiding him to do it in a good way would involve fixing it yourself in the explanation - and then you’d not show the code so he can do it himself? That’s just silly. If he cares about that he came out of that with quite a bit of experience on how to handle it the next time - and he mentions he even got an (assumed to be starter friendly) other issue suggested if he wants to have code in the kernel.
From the perspective of hiring people he turned this from a “nice work debugging a problem, might be a useful candidate” to “tries getting low quality code merged for vanity reasons, let’s avoid that guy”
I didn’t meant to defend the patch and I see your point. But I personally think that it’s not unreasonable to expect to land a bugfix commit after spending multiple days debugging a complex issue, that’s why understand that he feels robbed of a kernel contribution.
I don’t know what could have been a good solution for this scenario. But taking potential future contributors feelings more serious would help to keep them around and make them feel appreciated.
From the perspective of hiring people he turned this from a “nice work debugging a problem, might be a useful candidate” to “tries getting low quality code merged for vanity reasons, let’s avoid that guy”
The shit storm he brew up in response to getting feedback on his very first pull request is way more concerning than churning out low-quality code.
Coding skills can be improved, specially from the first pull request onward. Toxic behavior such as putting up very public smear campaigns in response to getting feedback on his very first patch submission is a major red flag, and is as toxic as it gets.
That’s roughly what I meant - he should’ve come out of that experience having learned a lot (there’s even an explanation why the other code is better on the mailing list), and had the option of working on a different problem (while he didn’t say which I assume it was selected to be more beginner friendly). And instead he’s throwing a temper tantrum - that’s too risky behaviour for hiring.
But the help and credit he got for days or weeks of unpaid work was basically nothing.
We should keep in mind that this is a one-sided account on how a mundane bugfix issue was handled. Grain of salt required.
Nevertheless, the blog author said he received feedback from members of the Linux kernel security mailing list. Even though I think he could have received more credit than reporting the issue, that was basically his contribution: he pinpointed where the bug was. He also contributed a couple of patches that were faulty and unusable, and the maintainer had to step in and roll out his own fix.
I understand that fixing a nontrivial bug is a badge of honor, and getting credit for critical contributions might have more implications than a warm feeling. However, if the submitted patches were unusable then what would be the desirable outcome? I mean, should Linux users be deprived of a bug fix because a first-timr contributor is struggling with putting together a working patch?
Good point, this could just misrepresentat the situation. I also haven’t looked over the mailing list thread and comments here are very salty.
But giving him the benefit of doubt of a nice potential contributer who just debugged a very hard issue and sending in a basic concept of a potential fix. I think it would be beneficial for their community to take the wish for more credit more serious and try to make him feel welcome. But I recognize it was probably hard to do in this case.
Overall I just wanted to recognize that I do see how he feels robbed of his contribution. It reminded me that I also had an experience with the kernel developers that made me not want to contribute again.
I think it would be beneficial for their community to take the wish for more credit more serious and try to make him feel welcome.
I think they did. Apparently the maintainer trusted the first-time contributor enough to propose tackling another bug.
If the goal is to get more contributions, I think that’s exactly what should happen. I feel the kernel maintainer is being treated unfairly.
Whining about getting extra work feels like the author didn’t intended to contribute anything else and just put all this reputation chips on that one isolated ticket.
Apparently the maintainer trusted the first-time contributor enough to propose tackling another bug.
There is no trust needed when asking someone to fix a bug. It’s not like the maintainer would lose anything if the contributor failed to fix the bug.
Besides, I think it is natural to want recognition when you do a lot of work for free. Many other people wouldn’t do this unpaid work at all; recognizing their contribution is the bare minimum of good manners. Even in a company where employees are paid for their work, it is customary to give credit to co-workers who have helped you. Most people don’t like to work in places where they don’t feel appreciated, and that is also true in Open-Source.
Unfortunately I don’t have my original patch, because I only sent that to the Linux security mailing list. I don’t think it’s a stupid thing to want to have code in the kernel, especially after spending all my time debugging this issue. The fix was trivial once I’ve pointed to the exact place where the buffer overflow happened and I should have received credit for all my effort.
You did receive credit. A good bug report allows reproducing and ideally fixing the issue - which can involve considerable effort. This is the difference between your report, and the one you linked from 6 years ago.
Like I said, I’d probably have added an additional thanks for that in my commit message - but I’m unfamiliar with the kind of reports this particular subsystem typically receives, so it is quite possible your report is just something average coming in there.
I personally prefer to include code suggesting a fix in my bug reports - but I usually don’t expect it to be just merged as I’m not familiar with surrounding code. I also don’t expect that to receive an additional mention - it’s just part of the report, and is often cleaner in demonstrating the issue than a problem description.
I don’t think it’s a stupid thing to want to have code in the kernel, especially after spending all my time debugging this issue.
The way that you jumped straight onto broadcasting drama when your very first Linux kernel patch stumbled on the code review stage is a major red flag.
I would hate to work with you because I would feel that I would be risking being subjected to a very public character attack each time I had to review one of your patches.
The way that you jumped straight onto broadcasting drama
I’m not broadcasting drama, I’m sharing my side of the story on my personal blog and distribute it to other social media platforms.
your very first Linux kernel patch stumbled on the code review stage
The patch didn’t stumble on the code review stage, the PowerPC maintainer didn’t want to accept patches from me and implemented his own fix.
I would hate to work with you because I would feel that I would be risking being subjected to a very public character attack each time I had to review one of your patches.
Why would you hate people who would describe their interactions with you? The only reason I see is that you would hate how you’ve dealt with them.
I’m not broadcasting drama, I’m sharing my side of the story on my personal blog and distribute it to other social media platforms.
That’s literally broadcasting drama.
I think you’ll be happier in the long run if you can forgive and move on.
Regardless of deserved credit your reputation in the kernel community will be that of a drama llama at least for awhile. Making a mountain out of a mole hill, will be remembered, does not play well with others.
I’m not saying you don’t deserve credit, but the method you went about emoting over this event will be noticed by community managers, not just the kernel community. Be aware of how your reputation is developed. Lots of us had to eat some humble pie in our career development.
If you had spun this in your personal blog on how you helped fix a kernel bug, and spoke of the positives, then you would be seen as more of a team player, plays well with others, doesn’t get bogged down on small issues.
Our character isn’t defined when times are good, but with how we deal with adversity.
There’s a difference between being a team player and a subservient pawn though - if the maintainer wanted to play as a team they would’ve suggested changes to the patch and accepted OP’s PR. As it happens they didn’t as they clearly have some sort of a power/superiority complex or something, or at best are dismissive of others to the detriment of the project they work on
Did a bit more digging through the mailing list (also looking through the links posted on the HN thread), and to me it looks a bit weird.
OP came up with an initial patch (Wed, Jun 1, 2022 at 12:36 PM) that wasn’t deemed to be good enough to be merged. Maintainer came up with a different patch (Tue, 7 Jun 2022 00:34:56 +1000) saying “but I wanted to fix it differently”. OP then posted a reworked patch (Fri Jun 10 17:15:49 AEST 2022) that looks a lot more similar to the maintainer’s patch.
The maintainer’s patch and OP’s reworked patch look quite similar, but from what I can see from the mailing list, the maintainer actually came up with that approach, and OP didn’t then credit the maintainer in his reworked patch. @kairos@programming.dev can you please clarify, what am I missing?
Between the initial patch and the maintainer’s patch there was a private conversation between me and the maintainer (I don’t have access to it because I’ve used my work email and since then I switched companies). I posted my reworked patch only for visibility, since by then they have accepted the maintainer’s patch. But I sent the reworked patch in private to the PowerPC maintainer, before sending it to the powerpc mailing list.
I’m surprised there’s not more discussion of the
gitGitHub co-author feature here.A simple co-author line in the final commit sounds like an appropriate way to use the best final code while also giving due credit.
I believe that is just a GitHub feature. Trailers are not some special field in the commit, just things at the end of the commit message. Sort of like an email signature. (Not a great example, I know.) My point is that the use of trailers will vary from project to project.
Good point!
It looks like GitLab doesn’t have Co-Author support yet, yet.
At least - as part of the git history - co-author notes in commits can survive a migration away from GitHub.
It’s not clear if the current GitHub implementation will be the long term accepted standard, of course.
I submitted a pull request to Vim and the maintainer thanked me, tweaked it, and my name is not in the commit history because of it. I use to be bitter about it, if only a little. So I know how you feel but I put significantly less time into mine so the magnitude of the feeling is much smaller for me. My name is still there in the GitHub pull request though. Just like your name is still in the commit itself and in the mailing list. Try not to fret too much about the specifics of your name being in the author field. It’s really just a technical detail.
It sucks but it is what it is. I don’t think treating this like you were slighted is appropriate.
To be fair, wasn’t the vim codebase entirely committed by a single person? He did that with everyone and, while I don’t agree with that at all, it reads less like elitism / stolen credit than this particular story.
I may be wrong about that, so feel free to correct me 😊 either way, people should be credited for the work they do! and preferably not in the footnotes of a commit authored by someone else that didn’t fix the bug
No, you’re correct, it definitely was all (or mostly) committed by Bram. That’s part of why I was saying it didn’t feel as bad but I didn’t think it was relevant to mention. But yes, you’re definitely correct.
Git has different fields for author and committer - and modifying a commit should leave the author field intact, and just change the committer field. It is possible that github does something weird (I’m usually not doing much in their web UI) - but coming from working with git directly I’d expect you to be present in the author field.
I didn’t write the content of that commit. Author and committer being different is for things like rebasing commits written by other people.
You mentioned a pull request, and that it got edited - which in my workflow is pulling the commit and amending it.
Okay, I probably misspoke about the technicalities. I opened a pull request, then they made a new commit and closed the PR (like it was an issue) and didn’t touch the commit. Hope that makes sense now.
I feel like the takeaway here should be that the experience of contributing to the project was not great. That’s it.
There is value in complaining, even if you don’t have solutions. You can only make people aware of the consequences that their actions have caused by telling them.
I don’t even take issue with him posting this publicly to his own Dev blog. I think its a perfectly fine piece of on-the-job experience OP has shared. Maybe in a few years he would like to come back to it with a different perspective.
I do however think that OP posting this here (and apparently other boards) is a choice I don’t agree with. I think OP would have been better served writing a response email to the maintainer, explaining how they felt. Beyond that, what can one do?
I feel like the takeaway here should be that the experience of contributing to the project was not great. That’s it.
I don’t think this is a valid summary. I think the first-time contributor had a rather self-centered approach to the bugfix, and turned a run-of-the-mill bugfix in a huge drama-riddled personal attack on a FLOSS maintainer for no good reason.
Only in the OP’s one-sided and vindictive account of the whole ordeal does the project maintainer have questionable behavior. The central theme of the one-sided account is also absurd, as if a kernel maintainer needs to wait around for first-timers to contribute a patch for them to “rob” it to have a commit to show for.
The whole soap opera is so regrettable, and the OP comes out not looking good at all.
Whew, here I was thinking it might be cool to try to contribute to some project, maybe even Linux! This thread shall serve as my reminder to never do that because that’s for god-tier emotionless techbros only.
[Sarcasm] Remember, being a dick to people is the only way to ensure that you’re caring about the code enough!
Whew, here I was thinking it might be cool to try to contribute to some project, maybe even Linux! This thread shall serve as my reminder to never do that because that’s for god-tier emotionless techbros only.
I’ve stumbled upon this blog post first in HackerNews, and the comments there make it quite clear that, even though it wouldn’t hurt to give more credit than merely reporting a bug, the author’s submission was flawed and subpar, and the rewrite that went in was undoubtedly better in every way.
I don’t think all this drama is waranted or justifiable. Also, if the first whiff of adversity bothers you and any feedback in a PR other than enthusiastic praise leaves you with a sour taste then collaborative work might not be for you, both as a participant and as someoje that everyone else has to endure.
Here is the original patch I sent to the Linux kernel security team: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg221962.html
So you have just re-posted an old email to the mailing list just so you can link to it, likely confusing everyone on that mailing list.
Yes, so people could see my original submission. Then I’ve explained the purpose of the forward when asked, I don’t see any problem with that.
The problem is your not the main character, and the purpose of the mailing list isn’t relitigating social drama.
I think it is common knowledge by now that the kernel community is a rather toxic space where abuse and elitism are the norm rather than the exception. If you are unwilling to put up with that, it’s probably the wrong community for you to join.
I am not really seeing any toxic behaviour here.
OP’s patch was largely based on code in
ptrace32.c, but that code actually looks quite bad. So maintainer applied a better fix. Maybeptrace32.cshould be updated to use code that’s more similar toptrace-fpu.cnow?So maintainer applied a better fix.
That in itself is the problem. If the kernel community wants to attract new contributors, mentorship is important and appreciation of effort is important, despite the result of that effort not being up to par yet.
The general consensus in kernel space is to “only care about the code” (to quote Linus Torvalds himself) and not about about people, while in reality when two human beings interact with one another, it’s never “just about the code”.
The kernel is already suffering from this behavior. The majority of people contributing do so for money. Hobbyists who contribute out of passion in their free time have already become a side show, being pushed out more and more by the ever-present elitism of people who can spend 50h a week becoming experts. On the other hand, the number of people willing to tolerate a hostile work environment just for money is decreasing rapidly.
The kernel code is already deteriorating, code is being merged without anyone ever reviewing it as nobody has the time, energy or patience. Unless the kernel community starts changing from the inside out, we will see real problems popping up more and more in the next ten years.
That in itself is the problem. If the kernel community wants to attract new contributors, mentorship is important and appreciation of effort is important, despite the result of that effort not being up to par yet.
Well it depends on the quality of the PR. If there are minor things wrong, you can point them out the the contributor and help them get their PR to a level you want…
If the PR is “Ok, thanks for pointing out where the issue is, but I’m going to have to rewrite your solution entirely” - what is the maintainer supposed to do? Take their PR, overwrite the solution, and git squash them together so the original contributor gets “credit” in form of being in the git history?
I doubt the maintainer would even consider that the contributor would feel “belittled and angry” if their fix wasn’t accepted at face value, or if they didn’t get enough credit would write an angry blog post about it. This whole article could have just been a report of “How I found a bug in the Kernel and helped fix it” - instead of something this negative
I doubt the maintainer would even consider that the contributor would feel “belittled and angry”
… illustrating my point.
This whole article could have just been a report of “How I found a bug in the Kernel and helped fix it” - instead of something this negative
I disagree. If noone spoke out about Linus Torvalds calling people “dumb fucks”, he would still be doing it. So criticism about how the community functions and which behavior is tolerated or even rewarded is essential if we ever want things to change. Did the author do the best job with this article? Probably not. That does not invalidate his experience though.
This whole article could have just been a report of “How I found a bug in the Kernel and helped fix it” - instead of something this negative
I disagree. If noone spoke out about Linus Torvalds calling people “dumb fucks”, he would still be doing it.
It’s kind of a leap from “not accepting a PR because the maintainer thought the code wasn’t good enough to accept it at face value - and the maintainer apparently didn’t care enough to give the contributor an extended code-review on how to fix it” vs “calling people “dumb fucks””
If a maintainer get a PR that’s bad and it would take an hour to write an explanation on how to fix it - and then hoping the end-result from the contributor is as expected, otherwise he’ll have to write another explanation on how to fix it and go back and forth for a while - vs - just spending that hour rewriting the fix himself - I’m pretty sure most maintainers just do it themselves.
When you actually work for a company and you’re working with other (junior) devs, you should go for the option of educating them on what’s wrong with their PR… But in this case - I don’t even know if the maintainer is doing this as a paid job or just in their spare time - but either way why would the maintainer spend time getting the PR right if it was apparently far off.
Did the author do the best job with this article? Probably not. That does not invalidate his experience though.
I didn’t say his experience was invalid, but his experience probably isn’t unusual. He could’ve taken this experience as “I contributed the QA and diagnosing part of this bugfix, but my code wasn’t up to par. Next time before submitting some random fix for a bug that I found (that wasn’t even “Up for grabs”) (or discussed how it should be fixed at all) - I should contact the maintainer first” - Instead it seems he found a bug, didn’t really report or communicate about it, because he wanted to race for a fix himself because he wanted to get recognition for actually creating the code the fixed the bug
I just want you to know the votes on your post pretty accurately reflect the ratio of developers I could train or hire (up) as lead developer to those I could not (down).
If anything, the vote count here skews better than I would have expected.
Hang in there and keep mentoring. It’s thankless, but you ultimately get paid more.
I think it is common knowledge by now that the kernel community is a rather toxic space where abuse and elitism are the norm rather than the exception.
Even in the blog post’s very one-sided account of the issue, there isn’t even a hint of elitism or toxic behavior. There was a bug report, the reporter submitted a patch, the patch was faulty and unusable, and the maintainer stepped in to put together a working fix. That’s it.
I would absolutely try to sue in this case. My experiences with very experienced specialists is not stellar at all. The amount of gatekeeping and sheer arrogance is frightening. I get it, nobody wants to work on the kernel. It’s an underpaid (presumably) and underappreciated task. I would probably become an asshole as well if I dedicated 90% of my free time to fixing obscure bugs in even more obscure architecture.
Disclaimer: I‘m not a kernel dev and my experience stems from interactions with maybe 100 people of varying stages of proficiency. Sadly, the more proficient, the less friendly they often were.
Edit: the amount of downvotes you get for saying something unpopular without being violent or abusive is showing the lack of guts to discuss something in a civilized manner. Shame on you.
eh? sue??? who??
The person who shamelessly took their work and profited from it (in reputation). Who else?
Yeah sue Linus Torvalds directly for 3 props and 1 or 2 thanks.
Best he can do is a thumbs up, no eye contact
Edit: the amount of downvotes you get for saying something unpopular without being violent or abusive is showing the lack of guts to discuss something in a civilized manner. Shame on you.
People aren’t discussing this because “try to sue in this case” is just an absurd concept - but okay.
Who are you going to sue and for what? His concept of recognition is just “getting his code into the kernel”? He could have written a blog post in the context of “How I found a bug in the Kernel and helped fix it” - He did contribute, he did the QA part and the diagnosing part, thats contributing.
But his post with the sentiment of “I did it all for nothing!” makes it seem like the goal was to get “recognition” and get his code into the repo… The goal is just to fix bugs, and he did contribute to that
Thank you for explaining. This helps me understand both his and this here situation.
First of all, I‘m totally ok with it being absurd. It was my impression that this person has been wronged and should be appropriately compensated for their (shit ton of) work. From the text, it seemed like there is a way to get this compensation (in the form of recognition of some sort).
I‘m totally fine with being told that he misrepresented the situation and he‘s more going off a principle here which would never be enforceable. If there were such a „standard“ for recognition for kernel controbution, one could definitely try to enforce it.
In general, I have no problem with standing corrected. What I do have a problem with is the way people in IT centric communities on lemmy (and reddit) behave in general.
Obviously you were kind enough to explain instead and without being violent or abusive. I highly respect that. Thanks again.
