[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20221006162413.858527-1-bryan.odonoghue@linaro.org>
Date: Thu, 6 Oct 2022 17:24:12 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: corbet@....net, linux@...mhuis.info,
konstantin@...uxfoundation.org, krzysztof.kozlowski@...aro.org,
linux-doc@...r.kernel.org, joe@...ches.com
Cc: linux-kernel@...r.kernel.org,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Subject: [PATCH v6 0/1] Fixup instructions around mailing recipients
V6:
- Drops distinction between dedicated and non-dedicated mailing lists
- I appreciate Akria's concern on keeping the text concise but OTOH I think
we should call out supporters and reviewers as well as the mailing
list(s) produced by get_maintainer as mail addresses which ought to be
mailed.
A little bit of extra text should hopefully help others get the right
list of recipients, with the least amount of additional text added as
possible.
V5:
- Drops get_maintainer.pl removal of supporter - Joe Perches
- Back to one standalone Documentation change - Krzysztof's suggested list
RESEND:
+ Akira
V4:
- Change the subject line of the series
Previous: Expand get_maintainer to be explicit about supporters
https://lore.kernel.org/all/20220930064629.329514-1-bryan.odonoghue@linaro.org/t/
- Update get_maintainer.pl to return "maintainer" for both "S: Supported"
and "S: Maintained" - Theodore Tso
For the purposes of sending a patch whether or not the maintainer is
listed as volunteer or paid is not really useful information.
Listing both as "maintainer" is clearer the end user.
- Incorporate Krzysztof's list of recipients into
Documentation/process/submitting-patches.rst.
- I didn't include the get_mainainter.pl example.
Comments from both Akira and Joe suggest to me the example is not that
useful.
- get_maintainer will no longer produce "supporter" so one could argue that
the documentation shouldn't refer to supporters however not all of the
potential output strings are documented and I've opted not to document
"chief penguin" either.
I'd like to focus on the particular case of supporters with some
reasonable knock-on documentation tweaks for the obvious gaps we've
identified in our discussion because "supporter" really means
"maintainer" and you absolutely have to mail that person to get your
patch into the right inbox.
V3:
- Drops change to get_maintainer.pl - Theodore
- Rewords around `get_maintainer --nogit-fallback` and gives an example
I think the document text now is clearer and should be more helpful to
others in getting their minimum submission list right every time.
V2:
https://lore.kernel.org/lkml/20220928003006.230103-1-bryan.odonoghue@linaro.org/T/#u
- Documentation/process
Added in text to also make clear subsystem mailing list should be
included - Krzysztof
- Changed get_maintainer.pl to print maintainer[supporter] or
maintainer[volunteer] depending on MAINTAINERS file. - Thorsten/Bryan
- Choose supporter and volunteer instead of supported and volunteer
Supporter and volunteer describe the role of the person whereas supported
and volunteer would describe an activity and a role which isn't
consistent. - Thorsten/Bryan
- I didn't change Documentation/process/5.Posting.rst
This file doesn't mention get_maintainer.pl and I was mostly aiming to
fixup the process around get_maintainer.pl. - Thorsten
- Myself and Thorsten discussed changing get_maintainer.pl, how it seems
like a desirable thing to do but also that "it might break scripts for
people" and it might.
I don't know if get_maintainer.pl is or should be considered to be a
stable interface and an explicit software contract but, making it clear a
supporter is also a maintainer seems like the right thing to do from a
transmission of information perspective.
There is still the option of just updating Documentation/process in
isolation.
V1:
- Sent a standalone change to Documentation/process stating
get_maintainer.pl email addresses marked "supporter" should be included
in a patch run.
Bryan O'Donoghue (1):
Documentation/process: Be more explicit about who to mail on patch
submission
Documentation/process/submitting-patches.rst | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--
2.37.3
Powered by blists - more mailing lists