14 ms·

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

by loeg 3y ago

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

FireBeyond 3y ago
And when your fix was the actual fix, but the maintainer rewrote it stylistically? Why should the maintainer get that credit?
- loeg 3y ago
  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.
CydeWeys 3y ago
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.
matrss 3y ago
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.
- jacquesm 3y ago
  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.
  - jxramos 3y ago
    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.
    - jacquesm 3y ago
      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.
      - dcow 3y ago
        [flagged]
        3y ago
bluGill 3y ago
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)
gorjusborg 3y ago
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.

by loeg 3y ago

FireBeyond 3y ago

And when your fix was the actual fix, but the maintainer rewrote it stylistically? Why should the maintainer get that credit?

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

CydeWeys 3y ago

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.

matrss 3y ago

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.

jacquesm 3y ago
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.
- jxramos 3y ago
  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.
  - jacquesm 3y ago
    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.
    - dcow 3y ago
      [flagged]
      - 3y ago

bluGill 3y ago

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)

gorjusborg 3y ago

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.