lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 28 Aug 2019 15:01:15 -0500
From:   Rob Herring <robh@...nel.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Ashish Kumar <ashish.kumar@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
        Kuldeep Singh <kuldeep.singh@....com>
Subject: Re: [EXT] Re: [Patch v4 1/3] dt-bindings: spi: spi-fsl-qspi: Add
 ls2080a compatibility string to bindings

On Tue, Aug 27, 2019 at 2:56 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Tue, Aug 27, 2019 at 10:50:05AM -0500, Rob Herring wrote:
> > On Thu, Aug 22, 2019 at 07:49:27PM +0100, Mark Brown wrote:
>
> > > Drop the dt-bindings:.
>
> > If you do 'git log --oneline Documentation/devicetree/bindings/' you'll
> > notice that SPI and ASoC are the oddballs now. I don't really care
> > except it does add to tribal knowledge needed regarding maintainers'
> > requirements.
>
> 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.

> 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
> things where I once reviewed a patch for a subsystem that made
> use of some subsystem I do maintain or where one patch in a
> series (perhaps even an already applied one) was relevant at some
> point so I'm doing quite a bit of triage that's purely based on
> the subject lines.

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.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ