[PATCH] doc: remove confusing command to send patch

[Thomas Monjalon]

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