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 <[email protected]> (commit_signer:2/3=67%)
>> Richard Henderson <[email protected]> (commit_signer:1/3=33%)
>> Thomas Huth <[email protected]> (commit_signer:1/3=33%)
>> Michael Tokarev <[email protected]> (commit_signer:1/3=33%)
>> Julian Brown <[email protected]> (commit_signer:1/3=33%)
>> [email protected] (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 <[email protected]> (supporter:IDE)
[email protected] (open list:All patches CC here)
[email protected] (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).
Paolo
