6 ms·

"Reported-by tag gives credit to people who find bugs and report them and it hopefully inspires them to help us again in the future." [1] Nothing about that sa

by mfru 3y ago

"Reported-by tag gives credit to people who find bugs and report them and it hopefully inspires them to help us again in the future." [1] Nothing about that says "I have debugged an issue and contributed actual code to fix it" in there. [1]: https://docs.kernel.org/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes https://docs.kernel.org/process/submitting-patches.html#usin...

jxramos 3y ago
I agree, it obscures all the heavy lifting debugging and validating and certifying with strong confidence the fix works and continues to work, the guy even tested it on newer kernel releases. Someone who exudes that much perseverance should be welcomed with open arms. These are the kind of go getter get stuff done type of individuals every company longs for.
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.
- 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.
Ajedi32 3y ago
There's no such thing as a "have-debugged-and-contributed-actual-code-to-fix-it:" tag. He didn't write the actual commit that fixed the issue, so he was credited in the commit message instead. That seems fine to me. The fact that they didn't include an entire paragraph detailing the exact nature of his contribution isn't a reason to blow this up into some big community drama with over 500 comments on Hacker News.
- Snild 3y ago
  > There's no such thing as a "have-debugged-and-contributed-actual-code-to-fix-it:" tag. "Based-on-patch-by:" and/or "Root-caused-by:" comes pretty close, I think. It may seem like a small difference, but I understand the author's disappointment.
  - Sprocklem 3y ago
    Those might be better, but neither is a tag that is used in kernel commits. There is a list of specific tags that are used, and specific conditions on their use. "Reported-by:" was not a wholly arbitrary choice of words by the maintainer.
    - Snild 3y ago
      AFAIK, there are no rules limiting what tags you may use -- you can make up your own if you like. And people have. Here's what the kernel git says right now: linux$ git log | sed -nE 's/^ *([^ ]+-by:).*$/\1/p' | tr '[:upper:]' '[:lower:]' | sort | uniq -c | egrep -v ' [0-9] ' 20 ack-by: 74 acked-and-tested-by: 195801 acked-by: 24 acked-for-backlight-by: 49 acked-for-mfd-by: 19 acked-in-principle-or-something-like-that-by: 21 acked-off-by: 10 analysed-by: 47 analyzed-by: 26 based-on-a-patch-by: 97 based-on-patch-by: 15 based-on-work-by: 128 bisected-by: 18 boot-tested-by: 37 build-tested-by: 147 co-authored-by: 4779 co-developed-by: 175 debugged-by: 60 diagnosed-by: 11 disliked-by: 11 eviewed-by: 51 fixed-by: 18 fix-suggested-by: 32 found-by: 48 generated-by: 19 improvements-by: 79 inspired-by: 18 located-by: 10 not-acked-by: 86 noticed-by: 30 original-by: 140 originally-by: 95 original-patch-by: 44 pointed-out-by: 14 proposed-by: 10 reivewed-by: 22 reported-and-acked-by: 12 reported-and-analyzed-by: 77 reported-and-bisected-by: 12 reported-and-debugged-by: 23 reported-and-suggested-by: 3017 reported-and-tested-by: 21 reported-bisected-and-tested-by: 58990 reported-by: 11 requested-and-tested-by: 363 requested-by: 10 review-by: 55 reviewd-by: 513 reviewed-and-tested-by: 304543 reviewed-by: 16 reviewed-off-by: 67 reviwed-by: 11 root-caused-by: 29 sigend-off-by: 10 signed-by: 157 signed-of-by: 2253448 signed-off-by: 59 singed-off-by: 54 spotted-by: 32 suggested-and-acked-by: 12 suggested-and-reviewed-by: 17 suggested-and-tested-by: 15568 suggested-by: 48 tested-and-acked-by: 22 tested-and-reported-by: 35 tested-and-reviewed-by: 62630 tested-by: 12 verified-by: My suggestions are both there (far less often than "Reported-by:", but that's not surprising). I think "Analyzed-by:", "Debugged-by", "Diagnosed-by", "Originally-by:", or "Original-patch-by:" would also have worked. If you don't filter out the tags with less than 10 uses, there are some fun ones. For example, "You're-my-ding-a-ling-by:" should be used more often. :)

by mfru 3y ago

jxramos 3y ago

I agree, it obscures all the heavy lifting debugging and validating and certifying with strong confidence the fix works and continues to work, the guy even tested it on newer kernel releases. Someone who exudes that much perseverance should be welcomed with open arms. These are the kind of go getter get stuff done type of individuals every company longs for.

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

Ajedi32 3y ago

There's no such thing as a "have-debugged-and-contributed-actual-code-to-fix-it:" tag. He didn't write the actual commit that fixed the issue, so he was credited in the commit message instead. That seems fine to me. The fact that they didn't include an entire paragraph detailing the exact nature of his contribution isn't a reason to blow this up into some big community drama with over 500 comments on Hacker News.

Snild 3y ago
> There's no such thing as a "have-debugged-and-contributed-actual-code-to-fix-it:" tag. "Based-on-patch-by:" and/or "Root-caused-by:" comes pretty close, I think. It may seem like a small difference, but I understand the author's disappointment.
- Sprocklem 3y ago
  Those might be better, but neither is a tag that is used in kernel commits. There is a list of specific tags that are used, and specific conditions on their use. "Reported-by:" was not a wholly arbitrary choice of words by the maintainer.
  - Snild 3y ago
    AFAIK, there are no rules limiting what tags you may use -- you can make up your own if you like. And people have. Here's what the kernel git says right now: linux$ git log | sed -nE 's/^ *([^ ]+-by:).*$/\1/p' | tr '[:upper:]' '[:lower:]' | sort | uniq -c | egrep -v ' [0-9] ' 20 ack-by: 74 acked-and-tested-by: 195801 acked-by: 24 acked-for-backlight-by: 49 acked-for-mfd-by: 19 acked-in-principle-or-something-like-that-by: 21 acked-off-by: 10 analysed-by: 47 analyzed-by: 26 based-on-a-patch-by: 97 based-on-patch-by: 15 based-on-work-by: 128 bisected-by: 18 boot-tested-by: 37 build-tested-by: 147 co-authored-by: 4779 co-developed-by: 175 debugged-by: 60 diagnosed-by: 11 disliked-by: 11 eviewed-by: 51 fixed-by: 18 fix-suggested-by: 32 found-by: 48 generated-by: 19 improvements-by: 79 inspired-by: 18 located-by: 10 not-acked-by: 86 noticed-by: 30 original-by: 140 originally-by: 95 original-patch-by: 44 pointed-out-by: 14 proposed-by: 10 reivewed-by: 22 reported-and-acked-by: 12 reported-and-analyzed-by: 77 reported-and-bisected-by: 12 reported-and-debugged-by: 23 reported-and-suggested-by: 3017 reported-and-tested-by: 21 reported-bisected-and-tested-by: 58990 reported-by: 11 requested-and-tested-by: 363 requested-by: 10 review-by: 55 reviewd-by: 513 reviewed-and-tested-by: 304543 reviewed-by: 16 reviewed-off-by: 67 reviwed-by: 11 root-caused-by: 29 sigend-off-by: 10 signed-by: 157 signed-of-by: 2253448 signed-off-by: 59 singed-off-by: 54 spotted-by: 32 suggested-and-acked-by: 12 suggested-and-reviewed-by: 17 suggested-and-tested-by: 15568 suggested-by: 48 tested-and-acked-by: 22 tested-and-reported-by: 35 tested-and-reviewed-by: 62630 tested-by: 12 verified-by: My suggestions are both there (far less often than "Reported-by:", but that's not surprising). I think "Analyzed-by:", "Debugged-by", "Diagnosed-by", "Originally-by:", or "Original-patch-by:" would also have worked. If you don't filter out the tags with less than 10 uses, there are some fun ones. For example, "You're-my-ding-a-ling-by:" should be used more often. :)