11/10/2023 12:22, Ferruh Yigit: > On 10/11/2023 11:20 AM, Thomas Monjalon wrote: > > 11/10/2023 10:41, 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 <tho...@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 <tho...@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@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@dpdk.org, Cc maintainers. > >>>> This is what I do: > >>>> git send-email --to dev@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@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 :) > > > > They should give high priority when they are Cc as well. > > > > The problem is that we may have patches with empty "To", > > especially for cover letters and new libs. > > There are indeed, for those cases I am putting 'dev' to "To:".
So it would be simpler to recommend a single method with maintainers as Cc.
