[PATCH] doc: remove confusing command to send patch

[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..


-- 
David Marchand