5 ms·

The linux kernel isn't a reward and while I empathize with the OP I would absolutely prefer a better solution to maintain than one from the community. So the ma

by inglor 3y ago

The linux kernel isn't a reward and while I empathize with the OP I would absolutely prefer a better solution to maintain than one from the community. So the maintainer was well within their rights. That said, it's so easy to just give people who contributed to the fix attribution, in Node.js we make a point of trying to give credit in release notes and add `Co-Authored-By:` to PRs where we took _some_ work people did in PRs and adapted it. When you maintain something for a while, credit often stops being important to you (you _are_ the maintainer of the area after all) so it's hard to remember that for new contributors it's often very important. Totally a loss for OP and that part of linux that the maintainer wasn't more attentive to the fact sharing credit (especially when deserved like in this case) was important to OP.

secondcoming 3y ago
It seems he did get credit in the ‘Reported-By’ tag.
- rootlocus 3y ago
  That doesn't give credit for 5 days of debugging. It gives credit for raising the issue, which was already done, six years prior.
  - hmottestad 3y ago
    Best way to get help with an issue is to post the wrong solution. I remember hearing that somewhere.
    - fragmede 3y ago
      Cunningham's Law.
    - PinkRidingHood 3y ago
      You could've demonstrated it by calling it the wrong name
  - layer8 3y ago
    The issue reported was arguably the lower-level one uncovered by the debugging. So I’d say they reported the result of their debugging.
    - FireBeyond 3y ago
      ... and their fix. ... and their results of forward regression testing. There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution. Ignoring that the maintainer literally moved one line of code (of about forty additions) and "contributed" it with himself as the author. I'd say the maintainer plagiarized OP's code.
      - autoexec 3y ago
        > There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution. I don't really understand that either. Someone found a problem, researched it, found and tested a solution, voluntarily offered a patch, and everyone wants to pretend that it was nothing? "It was only x lines", "it was a simple/trivial patch to an obscure project", "It wasn't done in the exact way they wanted it". What is wrong with some people! It was a bug that was reported years ago but nobody took the time to fix it. This guy put in the work and delivered, which in the end is what matters.
  - deleted 3y ago
    [deleted]
- mcv 3y ago
  But that's only credit for finding the bug, not fixing it. He put quite a lot of work into fixing the bug, and that credit got stolen by someone who merely rewrote his fix.
  - deleted 3y ago
    [deleted]
- pgeorgi 3y ago
  Since text in commit messages is free, a more accurate tag hurts noone but keeps the spirits up and encourages future work: Based-on-work-by, Investigated-by, ... Reported-by is more of a participation medal because it can mean anything including "yo dawg, kernel crashes when I look at it wrong"
- phendrenad2 3y ago
  That doesn't cover the scope of his contribution
reacharavindh 3y ago
I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!". This is not how a project reliant on community efforts could sustain itself. I always thought a project as big and respected as that of the linux-kernel would have folks who know better, and look out for the best interests of teh project while respecting new-comers. After all they were new when they started contributing? I dont think anybody in their right mind would advocate for a "not best" solution to be accepted just because a new-comer brought it. The right thing to do would have been - "Here, I have reviewed your patch. This and This are troubling because of this reason. I'd recommend re-writing this like that. Tell me if you need assistance with this, and I can help write that part" and co-author such a patch. That's how you get a good pipeline of future contributors who also care.
- shakow 3y ago
  > I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!" Frankly, I think that's a non-trivial problem to solve: how to get the assumedly better fix while not ruffling the feathers of the more junior contributor so not to discourage on-ramping. I guess the best way to do it would be to have a co-authored-by tag, or something akin.
  - ghosty141 3y ago
    I see multiple people saying the authors fix was in a way inferior. Where is this mentioned?
    - toyg 3y ago
      It was stated by the maintainer as the reason for discarding the author's contribution.
      - Sprocklem 3y ago
        What the maintainer actually said was [0]: > Thanks for your patch, but I wanted to fix it differently. Can you try the patch below and make sure it fixes the bug for you? Which to me, at least, reads very differently than claiming the author's patch is worse. [0] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/244387.html https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24... (Credit to nolist_policy for pointing this out upthread.)
FartyMcFarter 3y ago
> The linux kernel isn't a reward It certainly seems that you're correct judging by the article, in the worst possible way.

by inglor 3y ago

secondcoming 3y ago

It seems he did get credit in the ‘Reported-By’ tag.

rootlocus 3y ago
That doesn't give credit for 5 days of debugging. It gives credit for raising the issue, which was already done, six years prior.
- hmottestad 3y ago
  Best way to get help with an issue is to post the wrong solution. I remember hearing that somewhere.
  - fragmede 3y ago
    Cunningham's Law.
  - PinkRidingHood 3y ago
    You could've demonstrated it by calling it the wrong name
- layer8 3y ago
  The issue reported was arguably the lower-level one uncovered by the debugging. So I’d say they reported the result of their debugging.
  - FireBeyond 3y ago
    ... and their fix. ... and their results of forward regression testing. There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution. Ignoring that the maintainer literally moved one line of code (of about forty additions) and "contributed" it with himself as the author. I'd say the maintainer plagiarized OP's code.
    - autoexec 3y ago
      > There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution. I don't really understand that either. Someone found a problem, researched it, found and tested a solution, voluntarily offered a patch, and everyone wants to pretend that it was nothing? "It was only x lines", "it was a simple/trivial patch to an obscure project", "It wasn't done in the exact way they wanted it". What is wrong with some people! It was a bug that was reported years ago but nobody took the time to fix it. This guy put in the work and delivered, which in the end is what matters.
- deleted 3y ago
  [deleted]
mcv 3y ago
But that's only credit for finding the bug, not fixing it. He put quite a lot of work into fixing the bug, and that credit got stolen by someone who merely rewrote his fix.
- deleted 3y ago
  [deleted]
pgeorgi 3y ago
Since text in commit messages is free, a more accurate tag hurts noone but keeps the spirits up and encourages future work: Based-on-work-by, Investigated-by, ... Reported-by is more of a participation medal because it can mean anything including "yo dawg, kernel crashes when I look at it wrong"
phendrenad2 3y ago
That doesn't cover the scope of his contribution

reacharavindh 3y ago

I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!". This is not how a project reliant on community efforts could sustain itself. I always thought a project as big and respected as that of the linux-kernel would have folks who know better, and look out for the best interests of teh project while respecting new-comers. After all they were new when they started contributing? I dont think anybody in their right mind would advocate for a "not best" solution to be accepted just because a new-comer brought it. The right thing to do would have been - "Here, I have reviewed your patch. This and This are troubling because of this reason. I'd recommend re-writing this like that. Tell me if you need assistance with this, and I can help write that part" and co-author such a patch. That's how you get a good pipeline of future contributors who also care.

shakow 3y ago
> I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!" Frankly, I think that's a non-trivial problem to solve: how to get the assumedly better fix while not ruffling the feathers of the more junior contributor so not to discourage on-ramping. I guess the best way to do it would be to have a co-authored-by tag, or something akin.
- ghosty141 3y ago
  I see multiple people saying the authors fix was in a way inferior. Where is this mentioned?
  - toyg 3y ago
    It was stated by the maintainer as the reason for discarding the author's contribution.
    - Sprocklem 3y ago
      What the maintainer actually said was [0]: > Thanks for your patch, but I wanted to fix it differently. Can you try the patch below and make sure it fixes the bug for you? Which to me, at least, reads very differently than claiming the author's patch is worse. [0] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/244387.html https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24... (Credit to nolist_policy for pointing this out upthread.)

FartyMcFarter 3y ago

> The linux kernel isn't a reward It certainly seems that you're correct judging by the article, in the worst possible way.