3 ms·

I looked at the two patches, and TBH the time taken to write the final correct patch would be a fraction of the time needed to explain how to write a better pat

by hnfong 3y ago

I looked at the two patches, and TBH the time taken to write the final correct patch would be a fraction of the time needed to explain how to write a better patch. 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.

tjoff 3y ago
The time to write the patch is insignificant in this context.
that_guy_iain 3y ago
I would say that the author stated he asked for his patch to be accepted so he could be a contributor implies they weren't planning on contributing more. So it doesn't seem like a sceranio where they should spend that extra time.
- deleted 3y ago
  [deleted]
kazinator 3y ago
Not really. 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.
- jacquesm 3y ago
  A maintainer can't approve a patch that wasn't properly signed off, that's one of the very few rules set for patch submission that has nothing to do with the code but everything to do with the legal implications of including code that isn't properly attributed and an essential part in keeping the Linux kernel unencumbered. This is not some rubberstamp formality, it is an actual declaration of authorship and shields the kernel maintainers from possible claims of copyright infringement.
bhouston 3y ago
> TBH the time taken to write the final correct patch would be a fraction of the time needed to explain how to write a better patch. 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.
- hnfong 3y ago
  > 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. 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.
mplewis 3y ago
You're missing the point. "I can do it faster" discourages new contributors from wanting to help out ever again.
timeon 3y ago
> a fraction of the time needed to explain how to write a better patch He apparently had six years (since bug was reported) to do it. I think he surely could spend some time.
Arnavion 3y ago
>A person randomly shows up to report and attempt fix a bug in an "obscure"(?) architecture 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. https://news.ycombinator.com/item?id=37675328 https://news.ycombinator.com/item?id=37675328
- hnfong 3y ago
  > https://news.ycombinator.com/item?id=37675328 https://news.ycombinator.com/item?id=37675328 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.
  - Arnavion 3y ago
    And my point was that from "a utilitarian perspective" there's a middle ground between "coach the original author to produce a better patch" and "commit your own patch without crediting the original author"; it's "commit your own patch while crediting the original author". There's no "out of context" quoting in my comment.

by hnfong 3y ago

tjoff 3y ago

The time to write the patch is insignificant in this context.

that_guy_iain 3y ago

I would say that the author stated he asked for his patch to be accepted so he could be a contributor implies they weren't planning on contributing more. So it doesn't seem like a sceranio where they should spend that extra time.

deleted 3y ago
[deleted]

kazinator 3y ago

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

jacquesm 3y ago
A maintainer can't approve a patch that wasn't properly signed off, that's one of the very few rules set for patch submission that has nothing to do with the code but everything to do with the legal implications of including code that isn't properly attributed and an essential part in keeping the Linux kernel unencumbered. This is not some rubberstamp formality, it is an actual declaration of authorship and shields the kernel maintainers from possible claims of copyright infringement.

bhouston 3y ago

> TBH the time taken to write the final correct patch would be a fraction of the time needed to explain how to write a better patch. 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.

hnfong 3y ago
> 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. 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.

mplewis 3y ago

You're missing the point. "I can do it faster" discourages new contributors from wanting to help out ever again.

timeon 3y ago

> a fraction of the time needed to explain how to write a better patch He apparently had six years (since bug was reported) to do it. I think he surely could spend some time.

Arnavion 3y ago

>A person randomly shows up to report and attempt fix a bug in an "obscure"(?) architecture 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. https://news.ycombinator.com/item?id=37675328 https://news.ycombinator.com/item?id=37675328

hnfong 3y ago
> https://news.ycombinator.com/item?id=37675328 https://news.ycombinator.com/item?id=37675328 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.
- Arnavion 3y ago
  And my point was that from "a utilitarian perspective" there's a middle ground between "coach the original author to produce a better patch" and "commit your own patch without crediting the original author"; it's "commit your own patch while crediting the original author". There's no "out of context" quoting in my comment.