[PATCH] get_maintainer: ignore Tingting Meng

[PATCH] get_maintainer: ignore Tingting Meng

[Casey Connolly]

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@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@kernel.org>
+Tingting Meng <tingting.meng@altera.com>
-- 
2.53.0

Re: [PATCH] get_maintainer: ignore Tingting Meng

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

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@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@kernel.org>
> +Tingting Meng <tingting.meng@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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] get_maintainer: ignore Tingting Meng

[Casey Connolly]

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@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@kernel.org>
>> +Tingting Meng <tingting.meng@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?

Kind regards,

> 

-- 
// Casey (she/her)

Re: [PATCH] get_maintainer: ignore Tingting Meng

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

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@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@kernel.org>
> >> +Tingting Meng <tingting.meng@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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [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@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@kernel.org>
>>>> +Tingting Meng <tingting.meng@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,

> 

Re: [PATCH] get_maintainer: ignore Tingting Meng

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3451 bytes --]

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@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@kernel.org>
> > > > > +Tingting Meng <tingting.meng@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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [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@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@kernel.org>
>>>>>> +Tingting Meng <tingting.meng@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,>