On 09/08/2024 10:35, Joonas Lahtinen wrote: > 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. Indeed, sorry for that. It was quite grumpy from my side. > > 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? The entire confusion came because, while having latest next trees, the cherry picked commit SHA was nowhere to be found, so I assumed you just moved it between private/work-in-progress branches. Before drm-next hits linux-next (and I know you have different workflows), this confusion will be for everyone who does not have drm-next remote. And yes, processing unknown SHAs is a problem or inconvenience... which could be easily avoided even in your cherry-pick style - first apply to fixes and then cherry-pick (duplicate!) to drm-next. I understand that it is just quirk of DRM development style. While, I still disagree that duplicating commits which have 100% same diff hunks and context (zero difference) is good, that's just personal opinion and people can disagree. AFAIU, the double SoB is incidental, I guess. > > 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 Well, if you start using b4, which does much more, you notice that process does not make information lost. > 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. Sure. One more time apologies for grumpy response. Best regards, Krzysztof
