On Wed, Aug 28, 2019 at 03:01:15PM -0500, Rob Herring wrote: > On Tue, Aug 27, 2019 at 2:56 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Tue, Aug 27, 2019 at 10:50:05AM -0500, Rob Herring wrote: > > Well, you have been pushing people to change over to using > > dt-bindings: so I guess you do care :( > Well, yes. In the absence of any sort of pattern, I have pushed for > some consistency. And to get rid of subjects like this: > Documentation/devicetree/bindings: Add the DT binding documentation for foo-bar > If subsystems are consistent with their own standard as you are, then > as a maintainer I don't really care. My point was in regard to what > submitters need to know and follow. I agree that things should be more consistent. > > It really does cause me > > to miss stuff, especially where people don't even include the > > subsystem name in the header. I get quite a lot of CCs for > I can't imagine filtering on subjects will ever be that reliable > unless we add subject prefixes to MAINTAINERS and have checkpatch > check commits against those. Filtering on the diffstat is the only > thing that's kept things to a sane list for me (MAINTAINERS for DT > used to tag of_* functions which just meant getting copied on *every* > driver). This is done on the patchwork server side for me, but I > imagine one could do it on the client side too. Part of the problem for me here is that stuff that's flagged as just a binding has a very high chance of being misdirected, I'm unlikely to have much input unless it's for a driver or subsystem I maintain and I get a lot of bindings docs for things like other bits of MFDs that have a regulator on them or where there was some interesting interaction with one of my subsystems that hasn't yet filtered out of get_maintainers' view. The other trick here is that sometimes I am actually being asked about the thing that I'm getting CCed on so I don't want to actually filter stuff out of my inbox, it's more of a scoring system thing with lots of guessing going on. I say filtering but it's more a strong signal than strictly a filter.
Attachment:
signature.asc
Description: PGP signature
