lkml.org 
[lkml]   [2023]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v3 1/1] scripts: Add add-maintainer.py
    From
    On 30/08/2023 01:16, Guru Das Srinagesh wrote:
    > 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?

    Exactly, no one even knows what problem you want to solve by swapping
    To-Cc between patches...

    >
    > 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:".

    That's your feeling, quite subjective. I understand it comes from
    corporate world, but again...

    >
    > 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.

    It will not get traction because:
    1. People should use b4, not this script.
    2. Remaining people will just use get_maintainers.pl.
    3. People cannot get right even basic commands, so we will never be able
    to rely on To or Cc distinction. I can give you example: my email
    address in get_maintainers.pl is a bit different. Does it matter? Often
    not. Entire bunch of folks were Ccing me on different address. Even
    though every tool told them not to...

    > 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.

    Zero usefulness for me.

    Best regards,
    Krzysztof

    \
     
     \ /
      Last update: 2023-08-30 20:50    [W:7.837 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site