[PATCH] get_maintainer: ignore Tingting Meng

[Casey Connolly]

On 6/17/26 19:26, Tom Rini wrote:
> On Wed, Jun 17, 2026 at 05:03:52PM +0200, Casey Connolly wrote:
>> Hi Tom,
>>
>> On 16/06/2026 16:36, Tom Rini wrote:
>>> On Tue, Jun 16, 2026 at 03:11:26PM +0200, Casey Connolly wrote:
>>>
>>>> Their email is no longer valid and bounces, ensure we don't include it
>>>> in get_maintainer.pl output.
>>>>
>>>> Signed-off-by: Casey Connolly <casey.connolly at linaro.org>
>>>> ---
>>>>   .get_maintainer.ignore | 1 +
>>>>   1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/.get_maintainer.ignore b/.get_maintainer.ignore
>>>> index 899a1469b2ae..5b7d84646f62 100644
>>>> --- a/.get_maintainer.ignore
>>>> +++ b/.get_maintainer.ignore
>>>> @@ -1 +1,2 @@
>>>>   "Pali Rohár" <pali at kernel.org>
>>>> +Tingting Meng <tingting.meng at altera.com>
>>>
>>> The .get_maintainer.ignore file is a heavy-handed measure for things
>>> more serious than just bouncing email. It looks like Tingting Meng just
>>> comes up via git history and so will roll out of emails in a few months
>>> now, so I don't want to go this path.
>>
>> Ok, that makes sense. I have found bouncing emails and excessively long
>> CC lists to be a bit of a recurring email when using b4 prep
>> --auto-to-cc, do you have any ideas on how we can improve this?
>>
>> Maybe we could tighten the timeline and/or contribution weight a bit?
> 
> It's hard because we've had contributors at both ends of the spectrum
> speak up before. I think what Marek has been doing to use "N" to get
> more files covered by maintainers directly helps so that more things
> will always have someone else see them and in the future maybe we can
> try and lower the git range.

Hmm I see. I've been getting some feedback from folks who have 
contributed to Qualcomm support that they are being CC'd in too many 
patches as well.

If we will keep --git for then perhaps we could try and tune things a 
bit to be less aggressive? Maybe something like:

--git-min-percent 15 --git-since 4-months-ago --git-max-maintainers 2

Still less than ideal for defconfigs and such but at least it would 
reduce the huge CC lists that "b4" currently makes. I think 4 months is 
more reasonable than 1 year so things will cycle through faster and 
folks will still be notified about changes up to the next release.

That being said, if folks are speaking up about not being CC'd in 
patches that touch code they care about they really ought to add 
themselves to MAINTAINERS... We have board/qualcomm/MAINTAINERS for 
exactly this purpose.

The --git flags will never be perfect imho, but would you be ok with the 
changes above? Or any subset of those flags?

Thanks,

>