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 <[email protected]>
---
.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" <[email protected]>
+Tingting Meng <[email protected]>
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,>
