kernel-janitors.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <20210518052117.14819-1-lukas.bulwahn@gmail.com> (raw)

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


             reply	other threads:[~2021-05-18  5:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18  5:21 Lukas Bulwahn [this message]
2021-05-18  5:21 ` [RFC PATCH 1/1] MAINTAINERS: TTY LAYER: add some ./include/linux/ header files Lukas Bulwahn
2021-05-18  5:37   ` Jiri Slaby
2021-05-23  7:05     ` Lukas Bulwahn
2021-05-23  8:18       ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210518052117.14819-1-lukas.bulwahn@gmail.com \
    --to=lukas.bulwahn@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ralf.ramsauer@oth-regensburg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).