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. -- Tom
signature.asc
Description: PGP signature
