[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MN0PR12MB6101040D61CBD6E0E1B588E9E2AF9@MN0PR12MB6101.namprd12.prod.outlook.com>
Date: Fri, 17 Jun 2022 18:54:14 +0000
From: "Limonciello, Mario" <Mario.Limonciello@....com>
To: Jonathan Corbet <corbet@....net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Joe Perches <joe@...ches.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: RE: [PATCH 2/2] Documentation: Add a blurb about using
scripts/git-send-email.sh
[Public]
> -----Original Message-----
> From: Jonathan Corbet <corbet@....net>
> Sent: Friday, June 17, 2022 13:51
> To: Limonciello, Mario <Mario.Limonciello@....com>; Limonciello, Mario
> <Mario.Limonciello@....com>; linux-kernel@...r.kernel.org
> Cc: Joe Perches <joe@...ches.com>; linux-doc@...r.kernel.org
> Subject: Re: [PATCH 2/2] Documentation: Add a blurb about using scripts/git-
> send-email.sh
>
> Mario Limonciello <mario.limonciello@....com> writes:
>
> > In the part of the documentation explaining about identifying maintainers
> > mention the `scripts/git-send-email.sh` helper script.
> >
> > Suggested-by: Joe Perches <joe@...ches.com>
> > Signed-off-by: Mario Limonciello <mario.limonciello@....com>
> > ---
> > Documentation/process/submitting-patches.rst | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
>
> So if you used this script to send this series, I can already see a
> problem; I have a 2/2 patch without having seen the script that you are
> talking about. Bringing in maintainers partway through a patch series
> like this is not the best way to go.
Hmm; It's very situational. If you're working in a single subsystem then the
authoritative folks will be the maintainers in that subsystem, but perhaps
folks will also be interested in the other patches even if they're not authoritative.
This becomes particularly relevant when the patches will need to go through
one tree or the other.
In this particular case I'd actually think folding the script into the Documentation
patch makes the most sense.
For now; here's the direct link to this script patch:
https://lore.kernel.org/linux-kernel/20220617183215.25917-1-mario.limonciello@amd.com/T/#m163ce735a6422a037bb4f12009ebbd9db6985814
>
> > diff --git a/Documentation/process/submitting-patches.rst
> b/Documentation/process/submitting-patches.rst
> > index a1cb6280fbcf..039deed14c49 100644
> > --- a/Documentation/process/submitting-patches.rst
> > +++ b/Documentation/process/submitting-patches.rst
> > @@ -225,7 +225,10 @@ Select the recipients for your patch
> > ------------------------------------
> >
> > You should always copy the appropriate subsystem maintainer(s) on any
> patch
> > -to code that they maintain; look through the MAINTAINERS file and the
> > +to code that they maintain. A helper script is available in
> > +./scripts/git-send-email.sh that can be used with git-send-email to
> automatically
> > +findd the appropriate recipients for a patch.
>
> Please run a spelling checker on your documentation changes.
Oh whoops; sorry. I'm a bit surprised ./scripts/checkpatch didn't catch that.
>
> > +Alternatively you may look through the MAINTAINERS file manually and
> the
> > source code revision history to see who those maintainers are. The
> > script scripts/get_maintainer.pl can be very useful at this step (pass paths
> to
> > your patches as arguments to scripts/get_maintainer.pl). If you cannot
> find a
> > --
> > 2.25.1
>
> Thanks,
>
> jon
Powered by blists - more mailing lists