[PATCH] get_maintainer: ignore Tingting Meng

[Casey Connolly]

On 6/30/26 23:33, Tom Rini wrote:
> On Tue, Jun 30, 2026 at 09:18:35AM +0200, Casey Connolly wrote:
>>
>>
>> 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?
> 
> So, 4 months is only a bit more than one release cycle. Maybe 6, since
> we're currently at 12? And I don't disagree with saying we need more
> people to list themselves under MAINTAINERS if they're interested. The
> feedback has been less on board / platform code, and more on general
> code that just won't usually have a specific maintainer, and due to the
> slowness of testing cycles on a lot of platforms, it takes a while for
> corner cases to be found and reported on or a workaround / fix proposed.

Right I see, yeah that sounds reasonable. I'll send a patch then and see 
if anyone has other feedback. We could always try it for a cycle and 
revert it if there are issues.

Thanks,>