On 21/07/2023 08:26, [email protected] wrote:
> From: Boon Khai Ng <[email protected]>
>
> This patch is to add the dts setting for the MAC controller on
> synopsys 10G Ethernet MAC which allow the 10G MAC to turn on
> hardware accelerated VLAN stripping. Once the hardware accelerated
> VLAN stripping is turn on, the VLAN tag will be stripped by the
Subject prefix is totally bogus.
> 10G Ethernet MAC.
>
> Signed-off-by: Boon Khai Ng <[email protected]>
> Reviewed-by: Shevchenko Andriy <[email protected]>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.
You missed at least DT list (maybe more), so this won't be tested by
automated tooling. Performing review on untested code might be a waste
of time, thus I will skip this patch entirely till you follow the
process allowing the patch to be tested.
Please kindly resend and include all necessary To/Cc entries.
Best regards,
Krzysztof
> -----Original Message-----
> From: Krzysztof Kozlowski <[email protected]>
> Sent: Friday, July 21, 2023 6:11 PM
> To: [email protected]; [email protected]; "Ng
> <boon.khai.ng"@intel.com; Giuseppe Cavallaro <[email protected]>;
> Alexandre Torgue <[email protected]>; Jose Abreu
> <[email protected]>; David S . Miller <[email protected]>; Eric
> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
> Abeni <[email protected]>; Maxime Coquelin
> <[email protected]>; [email protected]; linux-stm32@st-md-
> mailman.stormreply.com; [email protected]; linux-
> [email protected]
> Cc: Ng, Boon Khai <[email protected]>; Shevchenko, Andriy
> <[email protected]>; Tham, Mun Yew <[email protected]>;
> Swee, Leong Ching <[email protected]>; G Thomas, Rohan
> <[email protected]>; Shevchenko Andriy
> <[email protected]>
> Subject: Re: [Enable Designware XGMAC VLAN Stripping Feature 1/2] dt-bindings:
> net: snps,dwmac: Add description for rx-vlan-offload
>
> On 21/07/2023 08:26, [email protected] wrote:
> > From: Boon Khai Ng <[email protected]>
> >
> > This patch is to add the dts setting for the MAC controller on
> > synopsys 10G Ethernet MAC which allow the 10G MAC to turn on hardware
> > accelerated VLAN stripping. Once the hardware accelerated VLAN
> > stripping is turn on, the VLAN tag will be stripped by the
>
> Subject prefix is totally bogus.
>
Which part? It's a 10G Ethernet IP from Sysnopsys, in Roman character it is X (mean 10), so XGMAC.
Even the driver file I'm editing it is dw"xgmac".
>
> > 10G Ethernet MAC.
> >
> > Signed-off-by: Boon Khai Ng <[email protected]>
> > Reviewed-by: Shevchenko Andriy <[email protected]>
>
> Please use scripts/get_maintainers.pl to get a list of necessary people and lists
> to CC. It might happen, that command when run on an older kernel, gives you
> outdated entries. Therefore please be sure you base your patches on recent
> Linux kernel.
>
This is based on net-next repository suggested by the get maintainer script.
I got the latest net-next just now at the Commit-id b44693495af8
which just committed yesterday.
$ ./scripts/get_maintainer.pl --scm -f drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
Giuseppe Cavallaro <[email protected]> (supporter:STMMAC ETHERNET DRIVER)
Alexandre Torgue <[email protected]> (supporter:STMMAC ETHERNET DRIVER)
Jose Abreu <[email protected]> (supporter:STMMAC ETHERNET DRIVER)
"David S. Miller" <[email protected]> (maintainer:NETWORKING DRIVERS)
Eric Dumazet <[email protected]> (maintainer:NETWORKING DRIVERS)
Jakub Kicinski <[email protected]> (maintainer:NETWORKING DRIVERS)
Paolo Abeni <[email protected]> (maintainer:NETWORKING DRIVERS)
Maxime Coquelin <[email protected]> (maintainer:ARM/STM32 ARCHITECTURE)
Richard Cochran <[email protected]> (maintainer:PTP HARDWARE CLOCK SUPPORT)
[email protected] (open list:STMMAC ETHERNET DRIVER)
[email protected] (moderated list:ARM/STM32 ARCHITECTURE)
[email protected] (moderated list:ARM/STM32 ARCHITECTURE)
[email protected] (open list)
git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
git git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> You missed at least DT list (maybe more), so this won't be tested by automated
> tooling. Performing review on untested code might be a waste of time, thus I
> will skip this patch entirely till you follow the process allowing the patch to be
> tested.
>
This is a new device bringup, thus the DT is not available yet. The DTS will be upstreamed
by my another colleague, unless, if I can upstream only my part on the setting?
> Please kindly resend and include all necessary To/Cc entries.
>
> Best regards,
> Krzysztof
On 21/07/2023 17:28, Ng, Boon Khai wrote:
> This is a new device bringup, thus the DT is not available yet. The DTS will be upstreamed
> by my another colleague, unless, if I can upstream only my part on the setting?
>
>> Please kindly resend and include all necessary To/Cc entries.
To be clear, since you do not agree with my comment you skipped vital
lists, this was not tested by automation so it is NAK from me.
Sorry.
Best regards,
Krzysztof
On 21/07/2023 17:28, Ng, Boon Khai wrote:
>> -----Original Message-----
>> From: Krzysztof Kozlowski <[email protected]>
>> Sent: Friday, July 21, 2023 6:11 PM
>> To: [email protected]; [email protected]; "Ng
>> <boon.khai.ng"@intel.com; Giuseppe Cavallaro <[email protected]>;
>> Alexandre Torgue <[email protected]>; Jose Abreu
>> <[email protected]>; David S . Miller <[email protected]>; Eric
>> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
>> Abeni <[email protected]>; Maxime Coquelin
>> <[email protected]>; [email protected]; linux-stm32@st-md-
>> mailman.stormreply.com; [email protected]; linux-
>> [email protected]
>> Cc: Ng, Boon Khai <[email protected]>; Shevchenko, Andriy
>> <[email protected]>; Tham, Mun Yew <[email protected]>;
>> Swee, Leong Ching <[email protected]>; G Thomas, Rohan
>> <[email protected]>; Shevchenko Andriy
>> <[email protected]>
>> Subject: Re: [Enable Designware XGMAC VLAN Stripping Feature 1/2] dt-bindings:
>> net: snps,dwmac: Add description for rx-vlan-offload
>>
>> On 21/07/2023 08:26, [email protected] wrote:
>>> From: Boon Khai Ng <[email protected]>
>>>
>>> This patch is to add the dts setting for the MAC controller on
>>> synopsys 10G Ethernet MAC which allow the 10G MAC to turn on hardware
>>> accelerated VLAN stripping. Once the hardware accelerated VLAN
>>> stripping is turn on, the VLAN tag will be stripped by the
>>
>> Subject prefix is totally bogus.
>>
>
> Which part? It's a 10G Ethernet IP from Sysnopsys, in Roman character it is X (mean 10), so XGMAC.
> Even the driver file I'm editing it is dw"xgmac".
Everything in [].
>
>>
>>> 10G Ethernet MAC.
>>>
>>> Signed-off-by: Boon Khai Ng <[email protected]>
>>> Reviewed-by: Shevchenko Andriy <[email protected]>
>>
>> Please use scripts/get_maintainers.pl to get a list of necessary people and lists
>> to CC. It might happen, that command when run on an older kernel, gives you
>> outdated entries. Therefore please be sure you base your patches on recent
>> Linux kernel.
>>
>
> This is based on net-next repository suggested by the get maintainer script.
>
> I got the latest net-next just now at the Commit-id b44693495af8
> which just committed yesterday.
>
> $ ./scripts/get_maintainer.pl --scm -f drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
That's not how you run it. get_maintainers.pl should be run on patches
or on all files, not just some selection.
> Giuseppe Cavallaro <[email protected]> (supporter:STMMAC ETHERNET DRIVER)
> Alexandre Torgue <[email protected]> (supporter:STMMAC ETHERNET DRIVER)
> Jose Abreu <[email protected]> (supporter:STMMAC ETHERNET DRIVER)
> "David S. Miller" <[email protected]> (maintainer:NETWORKING DRIVERS)
> Eric Dumazet <[email protected]> (maintainer:NETWORKING DRIVERS)
> Jakub Kicinski <[email protected]> (maintainer:NETWORKING DRIVERS)
> Paolo Abeni <[email protected]> (maintainer:NETWORKING DRIVERS)
> Maxime Coquelin <[email protected]> (maintainer:ARM/STM32 ARCHITECTURE)
> Richard Cochran <[email protected]> (maintainer:PTP HARDWARE CLOCK SUPPORT)
> [email protected] (open list:STMMAC ETHERNET DRIVER)
> [email protected] (moderated list:ARM/STM32 ARCHITECTURE)
> [email protected] (moderated list:ARM/STM32 ARCHITECTURE)
> [email protected] (open list)
> git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
> git git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
> git git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
>> You missed at least DT list (maybe more), so this won't be tested by automated
>> tooling. Performing review on untested code might be a waste of time, thus I
>> will skip this patch entirely till you follow the process allowing the patch to be
>> tested.
>>
>
> This is a new device bringup, thus the DT is not available yet. The DTS will be upstreamed
> by my another colleague, unless, if I can upstream only my part on the setting?
You are mixing now DTS and DT bindings. Sorry, we do not talk about DTS.
Follow our process of submitting patches. For sure there are folks in
Intel which can explain it to you.
Best regards,
Krzysztof
> -----Original Message-----
> From: Krzysztof Kozlowski <[email protected]>
> Sent: Saturday, July 22, 2023 12:22 AM
> To: Ng, Boon Khai <[email protected]>; [email protected];
> [email protected]; Giuseppe Cavallaro <[email protected]>;
> Alexandre Torgue <[email protected]>; Jose Abreu
> <[email protected]>; David S . Miller <[email protected]>; Eric
> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>;
> Paolo Abeni <[email protected]>; Maxime Coquelin
> <[email protected]>; [email protected]; linux-stm32@st-
> md-mailman.stormreply.com; [email protected]; linux-
> [email protected]
> Cc: Shevchenko, Andriy <[email protected]>; Tham, Mun Yew
> <[email protected]>; Swee, Leong Ching
> <[email protected]>; G Thomas, Rohan
> <[email protected]>; Shevchenko Andriy
> <[email protected]>
> Subject: Re: [Enable Designware XGMAC VLAN Stripping Feature 1/2] dt-
> bindings: net: snps,dwmac: Add description for rx-vlan-offload
>
> On 21/07/2023 17:28, Ng, Boon Khai wrote:
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <[email protected]>
> >> Sent: Friday, July 21, 2023 6:11 PM
> >> To: [email protected]; [email protected]; "Ng
> >> <boon.khai.ng"@intel.com; Giuseppe Cavallaro
> >> <[email protected]>; Alexandre Torgue
> >> <[email protected]>; Jose Abreu <[email protected]>;
> >> David S . Miller <[email protected]>; Eric Dumazet
> >> <[email protected]>; Jakub Kicinski <[email protected]>; Paolo
> Abeni
> >> <[email protected]>; Maxime Coquelin
> <[email protected]>;
> >> [email protected]; linux-stm32@st-md- mailman.stormreply.com;
> >> [email protected]; linux- [email protected]
> >> Cc: Ng, Boon Khai <[email protected]>; Shevchenko, Andriy
> >> <[email protected]>; Tham, Mun Yew
> >> <[email protected]>; Swee, Leong Ching
> >> <[email protected]>; G Thomas, Rohan
> >> <[email protected]>; Shevchenko Andriy
> >> <[email protected]>
> >> Subject: Re: [Enable Designware XGMAC VLAN Stripping Feature 1/2] dt-
> bindings:
> >> net: snps,dwmac: Add description for rx-vlan-offload
> >>
> >> On 21/07/2023 08:26, [email protected] wrote:
> >>> From: Boon Khai Ng <[email protected]>
> >>>
> >>> This patch is to add the dts setting for the MAC controller on
> >>> synopsys 10G Ethernet MAC which allow the 10G MAC to turn on
> >>> hardware accelerated VLAN stripping. Once the hardware accelerated
> >>> VLAN stripping is turn on, the VLAN tag will be stripped by the
> >>
> >> Subject prefix is totally bogus.
> >>
> >
> > Which part? It's a 10G Ethernet IP from Sysnopsys, in Roman character it is
> X (mean 10), so XGMAC.
> > Even the driver file I'm editing it is dw"xgmac".
>
> Everything in [].
>
> >
> >>
> >>> 10G Ethernet MAC.
> >>>
> >>> Signed-off-by: Boon Khai Ng <[email protected]>
> >>> Reviewed-by: Shevchenko Andriy <[email protected]>
> >>
> >> Please use scripts/get_maintainers.pl to get a list of necessary
> >> people and lists to CC. It might happen, that command when run on an
> >> older kernel, gives you outdated entries. Therefore please be sure
> >> you base your patches on recent Linux kernel.
> >>
> >
> > This is based on net-next repository suggested by the get maintainer script.
> >
> > I got the latest net-next just now at the Commit-id b44693495af8 which
> > just committed yesterday.
> >
> > $ ./scripts/get_maintainer.pl --scm -f
> > drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
>
> That's not how you run it. get_maintainers.pl should be run on patches or on
> all files, not just some selection.
>
> > Giuseppe Cavallaro <[email protected]> (supporter:STMMAC
> ETHERNET
> > DRIVER) Alexandre Torgue <[email protected]>
> > (supporter:STMMAC ETHERNET DRIVER) Jose Abreu
> <[email protected]>
> > (supporter:STMMAC ETHERNET DRIVER) "David S. Miller"
> > <[email protected]> (maintainer:NETWORKING DRIVERS) Eric
> Dumazet
> > <[email protected]> (maintainer:NETWORKING DRIVERS) Jakub
> Kicinski
> > <[email protected]> (maintainer:NETWORKING DRIVERS) Paolo Abeni
> > <[email protected]> (maintainer:NETWORKING DRIVERS) Maxime
> Coquelin
> > <[email protected]> (maintainer:ARM/STM32 ARCHITECTURE)
> > Richard Cochran <[email protected]> (maintainer:PTP HARDWARE
> > CLOCK SUPPORT) [email protected] (open list:STMMAC ETHERNET
> > DRIVER) [email protected] (moderated
> > list:ARM/STM32 ARCHITECTURE) [email protected]
> > (moderated list:ARM/STM32 ARCHITECTURE) [email protected]
> > (open list) git
> > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
> > git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
> > git git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
> > stm32-next git
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> >
> >> You missed at least DT list (maybe more), so this won't be tested by
> >> automated tooling. Performing review on untested code might be a
> >> waste of time, thus I will skip this patch entirely till you follow
> >> the process allowing the patch to be tested.
> >>
> >
> > This is a new device bringup, thus the DT is not available yet. The
> > DTS will be upstreamed by my another colleague, unless, if I can upstream
> only my part on the setting?
>
> You are mixing now DTS and DT bindings. Sorry, we do not talk about DTS.
>
> Follow our process of submitting patches. For sure there are folks in Intel
> which can explain it to you.
>
Ah see, so you were saying I'm missing the cc list of the maintainer related to the
DT binding.
>
> Best regards,
> Krzysztof
> -----Original Message-----
> From: Krzysztof Kozlowski <[email protected]>
> Sent: Saturday, July 22, 2023 12:26 AM
> To: Ng, Boon Khai <[email protected]>; [email protected];
> [email protected]; Giuseppe Cavallaro <[email protected]>;
> Alexandre Torgue <[email protected]>; Jose Abreu
> <[email protected]>; David S . Miller <[email protected]>; Eric
> Dumazet <[email protected]>; Jakub Kicinski <[email protected]>;
> Paolo Abeni <[email protected]>; Maxime Coquelin
> <[email protected]>; [email protected]; linux-stm32@st-
> md-mailman.stormreply.com; [email protected]; linux-
> [email protected]
> Cc: Shevchenko, Andriy <[email protected]>; Tham, Mun Yew
> <[email protected]>; Swee, Leong Ching
> <[email protected]>; G Thomas, Rohan
> <[email protected]>; Shevchenko Andriy
> <[email protected]>
> Subject: Re: [Enable Designware XGMAC VLAN Stripping Feature 1/2] dt-
> bindings: net: snps,dwmac: Add description for rx-vlan-offload
>
> On 21/07/2023 17:28, Ng, Boon Khai wrote:
> > This is a new device bringup, thus the DT is not available yet. The
> > DTS will be upstreamed by my another colleague, unless, if I can upstream
> only my part on the setting?
> >
> >> Please kindly resend and include all necessary To/Cc entries.
>
> To be clear, since you do not agree with my comment you skipped vital lists,
> this was not tested by automation so it is NAK from me.
>
> Sorry.
>
I understand that I already get a NAK at the beginning. But I don’t understand why,
Please don’t get me wrong, I'm not disagreeing your comments, was trying to understand
the reason behind and also which are the step that I made a mistake(s) on, this is to help
me to learn at the same time to smoothen the upstreaming process.
> Best regards,
> Krzysztof
On Fri, 21 Jul 2023 18:21:32 +0200 Krzysztof Kozlowski wrote:
> > $ ./scripts/get_maintainer.pl --scm -f drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
>
> That's not how you run it. get_maintainers.pl should be run on patches
> or on all files, not just some selection.
Adding Joe for visibility (I proposed to print a warning when people
do this and IIRC he wasn't on board).
On Fri, 2023-07-21 at 18:55 -0700, Jakub Kicinski wrote:
> On Fri, 21 Jul 2023 18:21:32 +0200 Krzysztof Kozlowski wrote:
> > > $ ./scripts/get_maintainer.pl --scm -f drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> >
> > That's not how you run it. get_maintainers.pl should be run on patches
> > or on all files, not just some selection.
>
> Adding Joe for visibility (I proposed to print a warning when people
> do this and IIRC he wasn't on board).
What's the issue here? Other than _how_ the script was used,
I don't see an actual problem with the script itself.
https://lore.kernel.org/lkml/[email protected]/
As far as I can tell, the patch series address list was identical
for the 0/2, 1/2, and 2/2 submissions:
--------------------------------
0/2:
From: [email protected], [email protected], "Ng <boon.khai.ng"@intel.com
To: Giuseppe Cavallaro <[email protected]>,
Alexandre Torgue <[email protected]>,
Jose Abreu <[email protected]>,
"David S . Miller" <[email protected]>,
Eric Dumazet <[email protected]>,
Jakub Kicinski <[email protected]>, Paolo Abeni <[email protected]>,
Maxime Coquelin <[email protected]>,
[email protected], [email protected],
[email protected],
[email protected]
Cc: Boon Khai Ng <[email protected]>,
Shevchenko Andriy <[email protected]>,
Mun Yew Tham <[email protected]>,
Leong Ching Swee <[email protected]>,
G Thomas Rohan <[email protected]>,
Shevchenko Andriy <[email protected]>
Subject: [Enable Designware XGMAC VLAN Stripping Feature 0/2]
1/2:
From: [email protected], [email protected], "Ng <boon.khai.ng"@intel.com
To: Giuseppe Cavallaro <[email protected]>,
Alexandre Torgue <[email protected]>,
Jose Abreu <[email protected]>,
"David S . Miller" <[email protected]>,
Eric Dumazet <[email protected]>,
Jakub Kicinski <[email protected]>, Paolo Abeni <[email protected]>,
Maxime Coquelin <[email protected]>,
[email protected], [email protected],
[email protected],
[email protected]
Cc: Boon Khai Ng <[email protected]>,
Shevchenko Andriy <[email protected]>,
Mun Yew Tham <[email protected]>,
Leong Ching Swee <[email protected]>,
G Thomas Rohan <[email protected]>,
Shevchenko Andriy <[email protected]>
Subject: [Enable Designware XGMAC VLAN Stripping Feature 1/2] dt-bindings: net: snps,dwmac: Add description for rx-vlan-offload
2/2:
From: [email protected], [email protected], "Ng <boon.khai.ng"@intel.com
To: Giuseppe Cavallaro <[email protected]>,
Alexandre Torgue <[email protected]>,
Jose Abreu <[email protected]>,
"David S . Miller" <[email protected]>,
Eric Dumazet <[email protected]>,
Jakub Kicinski <[email protected]>, Paolo Abeni <[email protected]>,
Maxime Coquelin <[email protected]>,
[email protected], [email protected],
[email protected],
[email protected]
Cc: Boon Khai Ng <[email protected]>,
Shevchenko Andriy <[email protected]>,
Mun Yew Tham <[email protected]>,
Leong Ching Swee <[email protected]>,
G Thomas Rohan <[email protected]>,
Shevchenko Andriy <[email protected]>
Subject: [Enable Designware XGMAC VLAN Stripping Feature 2/2] net: stmmac: dwxgmac2: Add support for HW-accelerated VLAN Stripping
--------------------------------
vger has a limit on the number of recipients for a single email
so patch series that cc all possible recipients can be bounced
and not forwarded by vger.
So I think when submitting a patch series, it's necessary to send
just the cover letter to all mailing lists for all files/paths
modified by any file in the patch series and specific patches
are sent to maintainers, reviewers and the specific mailing lists
modified by the specific patch.
I use the scripts below to send patch series where a patch series
are the only files in individual directories.
(Well I used to use, I'm not actively reading or creating kernel patches right now)
$ cat ~/bin/to.sh
#!/bin/bash
opts="--nogit --nogit-fallback --norolestats --pattern-depth=1"
if [[ $(basename $1) =~ ^0000- ]] ; then
./scripts/get_maintainer.pl --nom $opts $(dirname $1)/*
else
maint=$(./scripts/get_maintainer.pl --nol $opts $1)
if [ "$maint" == "" ] ; then
echo "[email protected]"
else
echo "$maint"
fi
fi
$ cat ~/bin/cc.sh
#!/bin/bash
opts="--nogit --nogit-fallback --norolestats"
maint_file=$(mktemp -t XXXXXXXX.cc)
if [[ $(basename $1) =~ ^0000- ]] ; then
./scripts/get_maintainer.pl $opts $(dirname $1)/* | \
~/bin/remove_undesirable_emails.sh > $maint_file
count=$(wc -c $maint_file | cut -f1 -d" ")
if [[ $count -lt 512 ]] ; then
cat $maint_file
else
./scripts/get_maintainer.pl -nom -nor $opts $(dirname $1)/* | \
~/bin/remove_undesirable_emails.sh
fi
else
./scripts/get_maintainer.pl $opts $1 | \
~/bin/remove_undesirable_emails.sh > $maint_file
count=$(wc -l $maint_file | cut -f1 -d" ")
if [[ $count -gt 0 ]] ; then
cat $maint_file
else
./scripts/get_maintainer.pl --git --git-fallback --norolestats $1 | \
~/bin/remove_undesirable_emails.sh
fi
fi
rm -f $maint_file
$ cat ~/bin/remove_undesirable_emails.sh
grep -vPi "(?:\bIngo\s+Molnar\b)"
$
(nb: Ingo asked not to receive any emails from me)
And these scripts are used with git send-email with a .gitconfig block
[sendemail]
chainreplyto = false
thread = false
suppresscc = self
cccmd = ~/bin/cc.sh
tocmd = ~/bin/to.sh
These scripts would have added 2 mailing lists to patch 0/n:
[email protected] (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
[email protected] (open list:ARM/RISC-V/RENESAS ARCHITECTURE)
and it would also have had a different recipient list for 1/2 as well
$ ./scripts/get_maintainer.pl -f Documentation/devicetree/bindings/net/snps,dwmac.yaml
"David S. Miller" <[email protected]> (maintainer:NETWORKING DRIVERS)
Eric Dumazet <[email protected]> (maintainer:NETWORKING DRIVERS)
Jakub Kicinski <[email protected]> (maintainer:NETWORKING DRIVERS)
Paolo Abeni <[email protected]> (maintainer:NETWORKING DRIVERS)
Rob Herring <[email protected]> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Krzysztof Kozlowski <[email protected]> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Conor Dooley <[email protected]> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Richard Cochran <[email protected]> (maintainer:PTP HARDWARE CLOCK SUPPORT)
Geert Uytterhoeven <[email protected]> (supporter:ARM/RISC-V/RENESAS ARCHITECTURE)
Magnus Damm <[email protected]> (supporter:ARM/RISC-V/RENESAS ARCHITECTURE)
Alexandre Torgue <[email protected]> (in file)
Giuseppe Cavallaro <[email protected]> (in file)
Jose Abreu <[email protected]> (in file)
[email protected] (open list:NETWORKING DRIVERS)
[email protected] (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
[email protected] (open list)
[email protected] (open list:ARM/RISC-V/RENESAS ARCHITECTURE)
[clean up the CC list]
On Fri, 21 Jul 2023 20:32:44 -0700 Joe Perches wrote:
> On Fri, 2023-07-21 at 18:55 -0700, Jakub Kicinski wrote:
> > On Fri, 21 Jul 2023 18:21:32 +0200 Krzysztof Kozlowski wrote:
> > > That's not how you run it. get_maintainers.pl should be run on patches
> > > or on all files, not just some selection.
> >
> > Adding Joe for visibility (I proposed to print a warning when people
> > do this and IIRC he wasn't on board).
>
> What's the issue here? Other than _how_ the script was used,
> I don't see an actual problem with the script itself.
I just CCed you on another case. If people keep using get_maintainers
wrong, it *is* an issue with the script.
> I use the scripts below to send patch series where a patch series
> are the only files in individual directories.
The fact that most people end up wrapping get_maintainers in another
script is also a pretty strong indication that the user experience is
inadequate.
To be clear - I'm happy to put in the work to make the changes.
It's just that from past experience you seem to have strong opinions
which run counter to maintainers' needs, and I don't really enjoy
writing Perl for the sake of it.
On Mon, 2023-07-24 at 18:04 -0700, Jakub Kicinski wrote:
> [clean up the CC list]
>
> On Fri, 21 Jul 2023 20:32:44 -0700 Joe Perches wrote:
> > On Fri, 2023-07-21 at 18:55 -0700, Jakub Kicinski wrote:
> > > On Fri, 21 Jul 2023 18:21:32 +0200 Krzysztof Kozlowski wrote:
> > > > That's not how you run it. get_maintainers.pl should be run on patches
> > > > or on all files, not just some selection.
> > >
> > > Adding Joe for visibility (I proposed to print a warning when people
> > > do this and IIRC he wasn't on board).
> >
> > What's the issue here? Other than _how_ the script was used,
> > I don't see an actual problem with the script itself.
>
> I just CCed you on another case. If people keep using get_maintainers
> wrong, it *is* an issue with the script.
Silly. No it's not.
> > I use the scripts below to send patch series where a patch series
> > are the only files in individual directories.
>
> The fact that most people end up wrapping get_maintainers in another
> script is also a pretty strong indication that the user experience is
> inadequate.
Not a useful argument. Process and documentation are required.
> To be clear - I'm happy to put in the work to make the changes.
> It's just that from past experience you seem to have strong opinions
> which run counter to maintainers' needs, and I don't really enjoy
> writing Perl for the sake of it.
Does anyone? Knock yourself out doing whatever you like.
I do suggest you instead write wrapper scripts to get
the output you want rather than updating the defaults
for the script and update the process documentation
to let other people know what do to as well.
Something akin to?Mario Limonciello's suggestion back in 2022:
https://lore.kernel.org/lkml/[email protected]/
Hi Joe,
On Tue, Jul 25, 2023 at 6:22 AM Joe Perches <[email protected]> wrote:
> I do suggest you instead write wrapper scripts to get
> the output you want rather than updating the defaults
> for the script and update the process documentation
> to let other people know what do to as well.
>
> Something akin to Mario Limonciello's suggestion back in 2022:
>
> https://lore.kernel.org/lkml/[email protected]/
FTR, this is more or less what I am using to generate a script
to send out patches:
OUT=...
echo git send-email \\ > $OUT
# Add -cc
# Wrap comment inside $(: ...)
# Replace (...) in comment by [...]
# Replace ] at EOL by ) again
# Add continuation to EOL
scripts/get_maintainer.pl $* | \
tr -d \" | \
sed -e 's/^/--cc "/' \
-e 's/ (/" $(: /' \
-e 's/ (/ [/' -e 's/)/]/' \
-e 's/]$/)/' \
-e 's/$/ \\/' | \
tee -a $OUT
echo "*[0-9][0-9][0-9][0-9]-*.*" >> $OUT
After generation, I edit the script to
- Replace some --cc by --to,
- Add/remove some people,
and run "source $OUT" to send the patches...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 7/25/23 02:33, Geert Uytterhoeven wrote:
> Hi Joe,
>
> On Tue, Jul 25, 2023 at 6:22 AM Joe Perches <[email protected]> wrote:
>> I do suggest you instead write wrapper scripts to get
>> the output you want rather than updating the defaults
>> for the script and update the process documentation
>> to let other people know what do to as well.
>>
>> Something akin to Mario Limonciello's suggestion back in 2022:
>>
>> https://lore.kernel.org/lkml/[email protected]/
>
> FTR, this is more or less what I am using to generate a script
> to send out patches:
>
> OUT=...
> echo git send-email \\ > $OUT
> # Add -cc
> # Wrap comment inside $(: ...)
> # Replace (...) in comment by [...]
> # Replace ] at EOL by ) again
> # Add continuation to EOL
> scripts/get_maintainer.pl $* | \
> tr -d \" | \
> sed -e 's/^/--cc "/' \
> -e 's/ (/" $(: /' \
> -e 's/ (/ [/' -e 's/)/]/' \
> -e 's/]$/)/' \
> -e 's/$/ \\/' | \
> tee -a $OUT
> echo "*[0-9][0-9][0-9][0-9]-*.*" >> $OUT
>
> After generation, I edit the script to
> - Replace some --cc by --to,
> - Add/remove some people,
> and run "source $OUT" to send the patches...
>
> Gr{oetje,eeting}s,
My script is great for single subsystem patches as it gets all the right
people but I've found problems whenever it crosses multiple subsystems.
Many subsystem owners want to see the whole series of patches to
understand how they interact. So the group of patches needs to be
treated together which would need the wrapper to look at all patches
instead.