Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Lukas Bulwahn <lukas.bulwahn@gmail.com>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>
Cc:     Ralf Ramsauer <ralf.ramsauer@oth-regensburg.de>,
        kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
        Lukas Bulwahn <lukas.bulwahn@gmail.com>
Subject: [RFC PATCH 0/1] Mining maintainers for kernel headers
Date:   Tue, 18 May 2021 07:21:16 +0200
Message-Id: <20210518052117.14819-1-lukas.bulwahn@gmail.com>
Precedence: bulk

Greg, Jiri,

Some basic data mining on the kernel development process [1, 2, 3] showed that
various files in ./include currently do not have a maintainer formally assigned
with a section in the MAINTAINERS file.

This is a first semi-automatic attempt of mining a mapping of header files to
MAINTAINERS section.

Currently, the automated code analysis basically does the following steps:

  1. Heuristically map header files to the related source files.

    The heuristics basically uses ctags to obtain the prototypes within a
    header file and then elixir to identify in which these prototypes are
    defined. The header file is then mapped to the source file with the highest
    number of definitions for prototypes referred to. More fine-tuning may
    still be required here.

  2. Deterministically map these source files to its MAINTAINERS section.

    Simply, using get_maintainer.pl, we obtain all relevant MAINTAINERS sections
    for each source file linked to a header file above.

  3. Combine those two mappings to identify which header files should be best
     added to which section in the existing MAINTAINERS file.

    As of now, we simply take the one most relevant source file identified and
    map it to a maintainer section. However, as the mapping from step 1 does not
    map every header file to a source file, the overall suggestions for
    additions is still pretty incomplete.

  4. Manually review the suggestions and manually create the patch for some
     example sections.

    At this early stage, we look at some selective sections, review the
    suggestions made by this tool for a section, filter out suggestions that
    seem rather wrong and then manually create the patch to add files and
    patterns from ./include/linux to the appropriate section.

Hence, the provided additions in this patch should be correct, but are not
necessarily complete wrt. all header files in ./include/linux/ that actually
belong to the TTY LAYER.

As all of this work is still pretty early and experimental, please provide
feedback on its correctness or simply pick such change for your tree if it is
all okay to take for now (although not yet complete).

Also, criticism on the approach and the way providing such patches for
MAINTAINERS is welcome, e.g.:

Your suggestions need to have this specific quality before reaching out to me
or other kernel maintainers with patches of such kind.

Or: Please do not take up the maintainers' review time for such clean-up and
just keep MAINTAINERS in the state as it is. (I would hope that this MAINTAINERS
clean-up is worth my time to attempt it, and given some good heuristics and own
manual review, worth the time to pick up by the individual maintainers.)

Or: Please first work on this other clean-up topic in MAINTAINERS and then
afterwards clean up this aspect here.


[1] https://lore.kernel.org/lkml/alpine.DEB.2.21.2003090702440.3325@felia/#r
[2] https://lwn.net/Articles/842415/
[3] https://lists.elisa.tech/g/devel/message/1269


Thanks and best regards,

Lukas


Lukas Bulwahn (1):
  MAINTAINERS: TTY LAYER: add some ./include/linux/ header files

 MAINTAINERS | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
2.17.1