[PATCH] doc: remove confusing command to send patch

[Ferruh Yigit]

On 10/11/2023 9:30 AM, Bruce Richardson wrote:
> On Wed, Oct 11, 2023 at 10:03:07AM +0200, Thomas Monjalon wrote:
>> 11/10/2023 09:30, David Marchand:
>>> On Tue, Oct 10, 2023 at 6:26 PM Thomas Monjalon <thomas at monjalon.net> wrote:
>>>>
>>>> In the contributor guide, it was said that no need to Cc maintainers
>>>> for new additions, probably for new directories not having a maintainer.
>>>> There is no harm, and it is a good habit, to always Cc maintainers.
>>>>
>>>> Remove this case as it can mislead to not Cc maintainers when needed.
>>>>
>>>> Signed-off-by: Thomas Monjalon <thomas at monjalon.net>
>>>
>>> I agree Cc: maintainers should be the default / recommended way of
>>> sending patches.
>>>
>>> Just to convince myself, adding some meson skeleton for a "plop"
>>> library, adding an entry in the release notes and hooking in
>>> lib/meson.build:
>>> $ git show --stat
>>>  doc/guides/rel_notes/release_23_11.rst | 4 ++++
>>>  lib/meson.build                        | 1 +
>>>  lib/plop/meson.build                   | 2 ++
>>>
>>> $ ./devtools/get-maintainer.sh 0001-new-awesome-library.patch
>>>
>>> In this case, it translates to an empty To: list if you follow the
>>> example command line:
>>>    git send-email --to-cmd ./devtools/get-maintainer.sh --cc
>>> dev at dpdk.org 000*.patch
>>>
>>> We could add a default list of recipients if no maintainer is found by
>>> the script.
>>> And the next question is who should be in that list..
>>
>> Or we can send to dev at dpdk.org, Cc maintainers.
>> This is what I do:
>> git send-email --to dev at dpdk.org --cc-cmd devtools/get-maintainer.sh
>>
> +1 for this, mainly on the basis of it being what I do too! :-)
>

I am for "--to-cmd=./devtools/get-maintainer.sh --cc dev at dpdk.org"

To highlight response is expected from the maintainers, and community is
informed.

Also people may have filters to give higher priority to emails they are
in 'to' list, high priority is what we want from maintainers :)