<sjg1>
Tartarus: marex: Also isn't Pali often complaining that his patches languish...one would have thought he could take the time to review patches he is cc'd on?
<Tartarus>
sjg1: Well, he's getting CC'd about unrelated areas
<sjg1>
Tartarus: No, I mean it uses the tags on the patches
<Tartarus>
Probably because he touched a makefile at some point
<Tartarus>
sjg1: Then that's even stranger
<sjg1>
Tartarus: I replied...in each case he has touched a file, and recently
alpernebbi_ has joined #u-boot
alpernebbi has quit [Ping timeout: 245 seconds]
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
<sjg1>
Tartarus: I think it is reasonable that people who benefited from a review of a file change should contribute a review on a future change in that file
<Tartarus>
And then "who touched this last" for Makefiles and Kconfigs isn't generally useful
<Tartarus>
"I added a board/command, cc the last people to add boards/commands"
<Tartarus>
Thinking out loud, it'd be a lot more useful for if we have Fixes tag then cc people on that commit
sng_ has joined #u-boot
<sjg1>
Tartarus: It isn't just relevance though, it is contributing a review. There is give and take
sng has quit [Ping timeout: 246 seconds]
<marex>
Tartarus: should the board maintainers file also contain drivers and the like ?
<marex>
Tartarus: as F: entries I mean
<Tartarus>
marex: it would be good to, moving forward, yes
<Tartarus>
sjg1: OK, but it seems like we're not making good asks here
<Tartarus>
Other projects also disable this behavior, fwiw, in get_maintainer.pl (qemu for example)
<marex>
qemu upstream isn't a particularly great example
sng_ has quit [Remote host closed the connection]
sng has joined #u-boot
sng has quit [Ping timeout: 240 seconds]
alpernebbi_ has quit []
alpernebbi has joined #u-boot
<Tartarus>
sjg1: I think this gets back to wishing for better tooling. I don't think "you touched a file" works well, since there's so many false positives. I _think_ get_maintainer.pl's git blame mode, which isn't default, might be more useful
<Tartarus>
And I don't think anything has what I said above about "if fixes then cc people from original commit"
<Tartarus>
Pali notes when he's tagged for seemingly random changes, and I think most of his complaints are valid
<Tartarus>
hence the patch to just turn off looking at git history
<marex>
Tartarus: OTOH kernel people start grumbling when they are not CCed
<marex>
Tartarus: so there the get maintainer is far more aggresive, and CCes a lot of people
<marex>
Tartarus: I am really surprised that someone who flings their @kernel.org address like that cannot set up kernel-like mail filters
<marex>
Tartarus: +464 lines of that maintainers patch so far ... heh
<Tartarus>
Feel free to use the regex / wildcard stuff :)
<Tartarus>
And I wonder if the kernel having a more substantial MAINTAINERS file helps too, ie arch/arm/boot/dts/Makefile has an explicit line, so no one gets ding'd for new board added
<Tartarus>
(and I assume the new vendor subdir Makefiles do too)
<Tartarus>
Ah, no, they don't, but that'll probably get addressed soon'ish
<marex>
Tartarus: I do use a bit of regex
<marex>
Tartarus: patch is out
<Tartarus>
My first question is, you don't want an entry for the clock, etc, stuff, by itself, instead of having it in several places?
<marex>
Tartarus: eh ?
<marex>
Tartarus: what do you mean "by itself" ?
<Tartarus>
Well, top level MAINTAINERS, or getting a bit more fun and trying new things, arch/arm/mach-rmobile/MAINTAINERS, and "Renesas Clock drivers", F: drivers/clk/renesas/
<Tartarus>
Rather than under each boar
<Tartarus>
d
<marex>
Tartarus: I was under the impression that MAINTAINERS file should be board/ only ?
<marex>
Tartarus: is that not the case ?
<Tartarus>
There's no written rule
<Tartarus>
Linux has one 24k line top-level file
<Tartarus>
We have top level, and started out with board/ ones too
<Tartarus>
What makes sense to add on top? I don't know
<Tartarus>
sjg1 has already noted before that get_maintainer.pl is not his favorite tool :)
<Tartarus>
and lamented that there's no formal spec for MAINTAINERS
<marex>
Tartarus: indeed, I solely use get-maintainer as patman is not my favorite tool :)
<marex>
Tartarus: btw ideally get maintainer would look at the git history and just figure out the CC list , I think that's easiest, but oh well
<Tartarus>
Well, that's what it does oddly today :)
<Tartarus>
--git-blame might work better, I dunno
sng has joined #u-boot
<Tartarus>
Anyhow, why not add to the top-level MAINTAINERS file an entry for renesas clock drivers, pinctrl, etc
sng has quit [Remote host closed the connection]
<marex>
Tartarus: you mean, throw away all the effort I just put into finding out which board needs which driver and squash it all into top level MAINTAINERS file ?
<Tartarus>
I'm asking why you did it the way you did it, yes