6 ms·

"Reported-by" is absolutely not the appropriate level of recognition for Ariel's input. This would be suitable if he just raised the issue with the maintainer a

"Reported-by" is absolutely not the appropriate level of recognition for Ariel's input. This would be suitable if he just raised the issue with the maintainer along with some context. Instead, he put a lot of work into figuring out the nature of the problem and implementing a fix. This is very unethical conduct on the maintainer's part.

jacquesm 3y ago
> This is very unethical conduct on the maintainer's part. And this is why finding good maintainers for visible FOSS projects is hard. You know what's unethical conduct? Misrepresenting someone's words in a way that make them look bad. The maintainer did exactly what they usually do, I see absolutely nothing unexpected here, note that this was an unsolicited patch sent to a security mailing list. And this is typically how those are dealt with. To claim 'unethical conduct' is one small step removed from a formal complaint about the maintainer, and which is exactly the wrong message to send here. Witch hunts like this cause good people to leave FOSS projects. The maintainer could have given more credit but chose not to, that's the rules you play by when sending in unsolicited patches. If you must have credit then you should not contribute in this fashion.
- leereeves 3y ago
  > The maintainer could have given more credit but chose not to, that's the rules you play by when sending in unsolicited patches Is something like "we may accept your work and choose not to give you credit" actually stated somewhere when you sign up for or submit to that security mailing list? Because that's certainly not the usual rule for unsolicited work in other contexts.
  - jacquesm 3y ago
    You can read the LKML mailing list page for submitting patches: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html https://www.kernel.org/doc/html/v4.17/process/submitting-pat... Absolutely nowhere does it say that accepting your patch will lead to you automatically being given kernel contributor status, and to require that status on the basis of committing a single tiny patch that wasn't properly signed off and required work shows a different set of expectations than one that I would see as reasonable.
    - FireBeyond 3y ago
      To me there's a difference between having a commit bit ("kernel contributor status") and having a contribution that was accepted into the kernel. Now to look at this patch it looks Michael took the report, debugged, tested, and resolved the issue, when all he actually did is move a single line to outside of a conditional. > and required work shows a different set of expectations You're really stretching here, the only "required work" missing was a sign off, which Michael could have given. In any other environment, this would be plagiarism. And it looks morally poor.
      - jacquesm 3y ago
        Well, we're going to have to differ on that then. Michael - in my opinion - properly credited the OP for his contribution, he could have done a longer back and forth to coach the OP to present the 'perfect patch' but this is the wrong venue for that. Besides that the OP misrepresented the interaction to a degree that he loses my sympathy, he makes the maintainer come off like a dick when in fact that wasn't the case at all, the interchange was polite and to the point and exactly in line with what I'd expect from a kernel maintainer.
        dcow 3y ago
        [flagged]
      - yencabulator 3y ago
        > To me there's a difference between having a commit bit ("kernel contributor status") and having a contribution that was accepted into the kernel. Who do you think has the commit bit on the Linux repo? Hint: kernel contributors don't.
- junofan 3y ago
  10–20 good patches is probably the minimum baseline for a contributor. Merging a couple if statements into mainline verbatim is pretty iffy. This guy’s expectations are whack.
- wang_li 3y ago
  [flagged]
  - jacquesm 3y ago
    I don't think suggesting the current maintainers of the Linux kernel taking a hike is a very productive angle.
    - stonogo 3y ago
      I don't think extrapolating "one person who acts badly not being much of a loss" to "all maintainers should leave" is a good interpretation of what was said.
      - jacquesm 3y ago
        If this person is a wanker they all are, if this person should leave they all should leave. Absolutely nothing happened here that warrants such a response.
        wang_li 3y ago
        [flagged]
        jacquesm 3y ago
        You really should familiarize yourself a bit more with how contributions to the kernel work, especially because there is an excellent document that lays out exactly how contributions to the kernel are handled. You can find it here: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html https://www.kernel.org/doc/html/v4.17/process/submitting-pat...
        wang_li 3y ago
        No part of that document details out that if you fail to follow their exact ritual then they get to steal your code and include it as their own. In comments all over this thread you go on about OP not following the proper ritual to appease the Greg Kroah-Hartman, for the code not being significant enough, for being unsolicited, for not being exactly as some random maintainer would like it. None of that matters. What matters is that this guy's code is in the kernel, unattributed, with minimal changes. If the kernel maintainers feel the ritual wasn't followed, then they can reject the patch, not steal it.
amatecha 3y ago
Yes, it should have been under "Co-developed-by".
- jacquesm 3y ago
  No, because as the exchange between the maintainer and the OP explicitly mentions it wasn't properly signed off on. That's the requirement for that particular tag: that a submission is in principle ready to be applied.
  - FireBeyond 3y ago
    Tell us, what "development" did Michael do that warranted him getting credit, and the OP not?
    - jacquesm 3y ago
      Kazinator did a pretty good job at that, besides: Michael is not taking any credit, LKML is there for all to read. https://news.ycombinator.com/item?id=37675544 https://news.ycombinator.com/item?id=37675544
    - avgcorrection 3y ago
      The sticking point here seems to be the DCO, which the “signed off by” thing attests. With that attestation other people who sign-off to the DCO can carry the patch forward (maximum to a pull request against Linus' tree). Without it though you have a broken chain. But it ain't much of a sticking point. Most of the time it is just an oversight that can be pointed out and corrected. All it takes is for the maintainer to point it out and ask for it and then then the author to do it. (The patch author themselves need to do it or else there wouldn't be a point to the sign-off; forging a sign-off would defeat the purpose.)
nemetroid 3y ago
The "Reported-By" must be read in the context of the patch carrying that tag, and not in the context of the blog author's initial issue. The accepted patch has the following title: > powerpc/32: Fix overread/overwrite of thread_struct via ptrace Miculas is credited with identifying the low-level issue: ptrace is overwriting thread_struct. To me, that does recognize that Miculas did significant analysis work.

jacquesm 3y ago

> This is very unethical conduct on the maintainer's part. And this is why finding good maintainers for visible FOSS projects is hard. You know what's unethical conduct? Misrepresenting someone's words in a way that make them look bad. The maintainer did exactly what they usually do, I see absolutely nothing unexpected here, note that this was an unsolicited patch sent to a security mailing list. And this is typically how those are dealt with. To claim 'unethical conduct' is one small step removed from a formal complaint about the maintainer, and which is exactly the wrong message to send here. Witch hunts like this cause good people to leave FOSS projects. The maintainer could have given more credit but chose not to, that's the rules you play by when sending in unsolicited patches. If you must have credit then you should not contribute in this fashion.

leereeves 3y ago
> The maintainer could have given more credit but chose not to, that's the rules you play by when sending in unsolicited patches Is something like "we may accept your work and choose not to give you credit" actually stated somewhere when you sign up for or submit to that security mailing list? Because that's certainly not the usual rule for unsolicited work in other contexts.
- jacquesm 3y ago
  You can read the LKML mailing list page for submitting patches: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html https://www.kernel.org/doc/html/v4.17/process/submitting-pat... Absolutely nowhere does it say that accepting your patch will lead to you automatically being given kernel contributor status, and to require that status on the basis of committing a single tiny patch that wasn't properly signed off and required work shows a different set of expectations than one that I would see as reasonable.
  - FireBeyond 3y ago
    To me there's a difference between having a commit bit ("kernel contributor status") and having a contribution that was accepted into the kernel. Now to look at this patch it looks Michael took the report, debugged, tested, and resolved the issue, when all he actually did is move a single line to outside of a conditional. > and required work shows a different set of expectations You're really stretching here, the only "required work" missing was a sign off, which Michael could have given. In any other environment, this would be plagiarism. And it looks morally poor.
    - jacquesm 3y ago
      Well, we're going to have to differ on that then. Michael - in my opinion - properly credited the OP for his contribution, he could have done a longer back and forth to coach the OP to present the 'perfect patch' but this is the wrong venue for that. Besides that the OP misrepresented the interaction to a degree that he loses my sympathy, he makes the maintainer come off like a dick when in fact that wasn't the case at all, the interchange was polite and to the point and exactly in line with what I'd expect from a kernel maintainer.
      - dcow 3y ago
        [flagged]
    - yencabulator 3y ago
      > To me there's a difference between having a commit bit ("kernel contributor status") and having a contribution that was accepted into the kernel. Who do you think has the commit bit on the Linux repo? Hint: kernel contributors don't.
junofan 3y ago
10–20 good patches is probably the minimum baseline for a contributor. Merging a couple if statements into mainline verbatim is pretty iffy. This guy’s expectations are whack.
wang_li 3y ago
[flagged]
- jacquesm 3y ago
  I don't think suggesting the current maintainers of the Linux kernel taking a hike is a very productive angle.
  - stonogo 3y ago
    I don't think extrapolating "one person who acts badly not being much of a loss" to "all maintainers should leave" is a good interpretation of what was said.
    - jacquesm 3y ago
      If this person is a wanker they all are, if this person should leave they all should leave. Absolutely nothing happened here that warrants such a response.
      - wang_li 3y ago
        [flagged]
        jacquesm 3y ago
        You really should familiarize yourself a bit more with how contributions to the kernel work, especially because there is an excellent document that lays out exactly how contributions to the kernel are handled. You can find it here: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html https://www.kernel.org/doc/html/v4.17/process/submitting-pat...
        wang_li 3y ago
        No part of that document details out that if you fail to follow their exact ritual then they get to steal your code and include it as their own. In comments all over this thread you go on about OP not following the proper ritual to appease the Greg Kroah-Hartman, for the code not being significant enough, for being unsolicited, for not being exactly as some random maintainer would like it. None of that matters. What matters is that this guy's code is in the kernel, unattributed, with minimal changes. If the kernel maintainers feel the ritual wasn't followed, then they can reject the patch, not steal it.

amatecha 3y ago

Yes, it should have been under "Co-developed-by".

jacquesm 3y ago
No, because as the exchange between the maintainer and the OP explicitly mentions it wasn't properly signed off on. That's the requirement for that particular tag: that a submission is in principle ready to be applied.
- FireBeyond 3y ago
  Tell us, what "development" did Michael do that warranted him getting credit, and the OP not?
  - jacquesm 3y ago
    Kazinator did a pretty good job at that, besides: Michael is not taking any credit, LKML is there for all to read. https://news.ycombinator.com/item?id=37675544 https://news.ycombinator.com/item?id=37675544
  - avgcorrection 3y ago
    The sticking point here seems to be the DCO, which the “signed off by” thing attests. With that attestation other people who sign-off to the DCO can carry the patch forward (maximum to a pull request against Linus' tree). Without it though you have a broken chain. But it ain't much of a sticking point. Most of the time it is just an oversight that can be pointed out and corrected. All it takes is for the maintainer to point it out and ask for it and then then the author to do it. (The patch author themselves need to do it or else there wouldn't be a point to the sign-off; forging a sign-off would defeat the purpose.)

nemetroid 3y ago

The "Reported-By" must be read in the context of the patch carrying that tag, and not in the context of the blog author's initial issue. The accepted patch has the following title: > powerpc/32: Fix overread/overwrite of thread_struct via ptrace Miculas is credited with identifying the low-level issue: ptrace is overwriting thread_struct. To me, that does recognize that Miculas did significant analysis work.