Re: [PATCH] get_maintainer: ignore Tingting Meng

[Tom Rini <trini@konsulko.com>]

[-- 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 --]