On 10/08/2017 11:35, Peter Maydell wrote:
>> actual default for un-matched: "recent contributors" + qemu-devel@
>> $ ./scripts/get_maintainer.pl -f disas.c
>> get_maintainer.pl: No maintainers found, printing recent contributors.
>> get_maintainer.pl: Do not blindly cc: them on patches! Use common sense.
>> Peter Maydell <peter.mayd...@linaro.org> (commit_signer:2/3=67%)
>> Richard Henderson <r...@twiddle.net> (commit_signer:1/3=33%)
>> Thomas Huth <th...@redhat.com> (commit_signer:1/3=33%)
>> Michael Tokarev <m...@tls.msk.ru> (commit_signer:1/3=33%)
>> Julian Brown <jul...@codesourcery.com> (commit_signer:1/3=33%)
>> email@example.com (open list:All patches CC here)
>> I find the un-matched "recent contributors" list often confuse, due to files
>> being moved, header updated, checkpatch indented.
> Yes, the recent-contributors list is often unhelpful, which
> is partly why the script warns about them. We might perhaps
> switch the default to --no-git-fallback".
Note that if a patch touches both maintained and unmaintained files, the
recent contributors list is omitted:
$ scripts/get_maintainer.pl -f util/cutils.c hw/ide/core.c
John Snow <js...@redhat.com> (supporter:IDE)
firstname.lastname@example.org (open list:All patches CC here)
qemu-bl...@nongnu.org (open list:IDE)
"--no-git-fallback" is probably the right thing to do when sending a
patch series. The maintainer that shepherds the series will take care
of unmaintained files too.
However, when sending a single patch to an unmaintained file the
contributors list usually does get the patch to the inbox of a
maintainer. This increases the odds of getting someone's attention.
Because inexperienced contributors usually don't send large series, my
feeling is that overall "--git-fallback"'s advantage are more than the
disadvantages, especially with the above logic that was introduced in
commit c6561586f0 ("get_maintainer.pl: restrict cases where it falls
back to --git", 2014-10-23).