On Aug 28 2023 21:45, Krzysztof Kozlowski wrote: > On 28/08/2023 21:41, Mark Brown wrote: > > On Mon, Aug 28, 2023 at 07:59:54PM +0200, Krzysztof Kozlowski wrote: > >> On 28/08/2023 19:56, Guru Das Srinagesh wrote: > > > >>> Your function adds mailing lists also in "To:" which is not ideal, in my view. > >>> You've mentioned before that To or Cc doesn't matter [1] which I disagree > >>> with: it doesn't matter, why does Cc exist as a concept at all? > > > >> To/Cc does not matter when sending new patch, because maintainers know > >> they are maintainers of which parts. I know what I handle. > > > > That might be true for you (and also is for me) but I know there are > > people who pay attention to if they're in the To: for various reasons, I > > gather it's mostly about triaging their emails and is especially likely > > in cases where trees have overlaps in the code they cover. > > True, there can be cases where people pay attention to addresses of > emails. Just like there are cases where people pay attention to "To/Cc" > difference. > > In my short experience with a few patches sent, no one complained to me > that I put him/her/they in "To" field of a patch instead of "Cc" (with > remark to not spamming to much, so imagine I send a patch for regulator > and DTS). Big, multi-subsystem patchsets are different case and this > script does not solve it either. Not sure what you mean by "does not solve it" - what is the problem being referred to here? In case of multi-subsystem patches in a series, the commit message of this patch explains exactly the actions taken. > Anyway, if it is not ideal for Guru, I wonder how his LKML maintainer > filters work that it is not ideal? What is exactly not ideal in > maintainer workflow? I am not a maintainer - only an individual contributor - and as such, even though I may get patches on files I've contributed to, I deeply appreciate the distinction between being Cc-ed in a patch vs To-ed in one. The distinction being that if I'm in "To:" I ascribe higher priority to it and lesser if I'm in "Cc:". If this script is accepted and gains adoption, maintainers like yourself will only be To-ed in patches that touch files that you're a direct "Maintainer" or "Reviewer" of. For all other patches in the series you'll be in "Cc:". I imagine that this can be very useful regardless of the specifics of your workflow. Also, lists should just be in "Cc:" - that's just my personal preference, but one that I'm sure others also share. Guru Das.
