Quoting Krzysztof Kozlowski (2024-08-08 21:44:39) > On 08/08/2024 20:35, Krzysztof Kozlowski wrote: > > On 08/08/2024 10:45, Tvrtko Ursulin wrote: > >> > >> Hi Dave, Sima, > >> > >> A small bunch of fixes for the weekly cycle: > > > > ... > > > >> > >> ---------------------------------------------------------------- > >> Andi Shyti (2): > >> drm/i915/gem: Adjust vma offset for framebuffer mmap offset > >> drm/i915/gem: Fix Virtual Memory mapping boundaries calculation > >> > >> David Gow (2): > >> drm/i915: Allow evicting to use the requested placement > >> drm/i915: Attempt to get pages without eviction first > >> > >> Dnyaneshwar Bhadane (1): > >> drm/i915/display: correct dual pps handling for MTL_PCH+ > > > > Several commits have issues. Look: > > > > Signed-off-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > Link: https://patchwork.freedesktop.org/patch/msgid ... > > (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) > > Signed-off-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > > > > > 1. Duplicated committer SoB. > > You added SoB. No need to add two. It does not get stronger. You do not > > change the DCO rules by adding two SoBs. You cannot confirm something > > more or twice. Read DCO one more time... Hi Krzysztof, As a self-proclaimed quite active kernel developer (by a quick web search) you might have already ventured to look at the GIT history of the subsytem tree for the patch in question. If you did that, you might have implied that the second S-o-b is added by automation -- and it indeed is. While appreciating the report, maybe not so much the the condescending style of the communication. You now slightly come through as a troll hoping to be fed - I hope that is not the case. Seems like we've had such a double S-o-b regularly generated by DIM (Drm Inglorious Maintainer scripts) at least since 2016 as the first occurrance seems to have been in ccda3a728f70 . So rest of the ecosystem seems to deal with them just fine. Is the double S-o-b issue purely cosmetic for you? Not a lawyer but I don't think there is any legal problem in stating the same thing twice. [1] Or are you maybe running into some more concrete issues with upstream kernel process related scripts or other automation processing of the commit? Regards, Joonas [1] When it comes to the commit rights model in DRM subsystem, stripping the final S-o-b after the cherry-pick would make it less obvious who did the pick. If there are multiple S-o-bs and the cherry-picking person happened to be one of them, that information would be lost. Less predictable outcome for the patch form for no actual gain in my opinion. On the other hand, removing the S-o-b line from above the "(cherry-picked.." line would modify the cherry-picked commit description itself and I would assume everyone agrees that should not be done.
