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#usin...
(Sure, in the same situation I would prefer to also be credited with authorship too. But I get it.)
Generally most of the work occurs after a bug is reported, as it did here.
Authoring the patch is often trivial once the debugging is done. Describing the debugging as just reporting is underselling it.
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.
Or you're adding some personal other experiences? (What are those? People yelling at you because you did attribute someone for the work they did?)
My understanding is that if the initial patch was not signed off then the maintainer could not sign off his patch, unless he wanted to take on the liability of certifying that the contributor was indeed allowed to contribute the initial patch under whatever license we are talking about here. That sounds like a legal risk I would not be willing to take.
The OP has submitted a link to an email archive further down in the thread.
> Yes, and that was one of the reasons the maintainer rewrote it (which wasn't a lot of work since it was a tiny patch anyway).
I don't think a simple rewrite is enough to convincingly solve the described problem. There is a reason "clean room design" exists and considering the maintainer read the original patch first before creating their own there is a good argument that they were at least subconsciously inspired by the original patch and therefore plagiarized. That is how I understand the legal aspects of this, anyway.
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.
"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.
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:
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. :)