linux-kernel - Re: [Ksummit-discuss] [RFC PATCH 2/3] MAINTAINERS, Handbook: Subsystem Profile

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]

Message-ID: <f08820b05467cc95cc195a2639595c0274c95d69.camel@perches.com>
Date:   Fri, 16 Nov 2018 09:56:59 -0800
From:   Joe Perches <joe@...ches.com>
To:     Jani Nikula <jani.nikula@...el.com>,
        Julia Lawall <julia.lawall@...6.fr>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     ksummit-discuss@...ts.linuxfoundation.org,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        vishal.l.verma@...el.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stfrench@...rosoft.com, Greg KH <gregkh@...uxfoundation.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        "Tobin C. Harding" <me@...in.cc>
Subject: Re: [Ksummit-discuss] [RFC PATCH 2/3] MAINTAINERS, Handbook:
 Subsystem Profile

On Fri, 2018-11-16 at 14:44 +0200, Jani Nikula wrote:
> I quickly cooked up this script to produce the top-5 commit prefixes for
> the given files over the arbitrary last 200 commits. It'll give you a
> pretty good idea if you're even close.
> 
> ---
> #!/bin/sh
> # usage: subject-prefix FILE [...]
> # show top 5 subject prefixes for FILEs
> 
> git log --format=%s -n 200 -- "$@" |\
> 	grep -v "^Merge " |\
> 	sed 's/\(.*\):.*/\1/' |\
> 	sort | uniq -c | sort -nr | sed 's/ *[0-9]\+ //' |\
> 	head -n 5
> ---
> 
> Someone who knows perl could turn that into a checkpatch check: See if
> the patch subject prefix is one of the top-5 for all files changed by
> the patch, and ask the user to double check if it isn't. Or some
> heuristics thereof.

This won't work when a patch contains multiple files
from different paths, or even multiple files from a
single driver.

Perhaps it's better to use a generic mechanism like

	basename $(dirname $filename):

with some exceptions and add an override patch subject
grammar to appropriate various sections of MAINTAINERS.

I also think it's better to use a separate script like
scripts/spdxcheck.py and tie any necessary checkpatch
use to that script.