Re: [PATCH v4 00/10] Auto-generate maintainer profile entries

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

On Sun, 03 May 2026 09:49:41 -0600
Jonathan Corbet <corbet@lwn.net> wrote:

> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> 
> > Hi Jon,
> >
> > This is basically the same patch series I sent during the merge
> > window, rebased on the top of post 7.1-rc1 docs-next branch.
> > It is tested both with and without O=DOCS.
> >
> > It contains just one extra trivial patch adding a missing SPDX
> > header, and, on v4, I dropped two patches touching MAINTAINERS,
> > as those aren't needed anymore.
> >
> > This patch series change the way maintainer entry profile links
> > are added to the documentation. Instead of having an entry for
> > each of them at an ReST file, get them from MAINTAINERS content.
> >
> > That should likely make easier to maintain, as there will be a single
> > point to place all such profiles.
> >
> > The output is a per-subsystem sorted (*) series of links shown as a
> > list like this:
> >
> >     - Arm And Arm64 Soc Sub-Architectures (Common Parts)
> >     - Arm/Samsung S3C, S5P And Exynos Arm Architectures
> >     - Arm/Tesla Fsd Soc Support
> >     ...
> >     - Xfs Filesystem
> >
> > Please notice that the series is doing one logical change per patch.
> > I could have merged some changes altogether, but I opted doing it
> > in small steps to help reviews. If you prefer, feel free to merge
> > maintainers_include changes on merge.
> >
> > There is one interesting side effect of this series: there is no
> > need to add rst files containing profiles inside a TOC tree: Just
> > creating the file anywhere inside Documentation and adding a P entry
> > is enough. Adding them to a TOC won't hurt.  
> 
> One thing I kind of dislike about these magic mechanisms is that we end
> up with a single, essentially unsorted list of stuff that readers have
> to go digging their way through.  It would be nice if we could somehow
> apply a bit of structure; as the number of these handbooks grows, our
> readers would appreciate it.

The output is sorted by subsystem's name:

	for profile, entry in sorted(maint.profile_entries.items()):
	    if entry.startswith("http"):
		output += f"- `{profile} <{entry}>`_\n"
            else:
		output += f"- :doc:`{profile} <{entry}>`\n"

But yeah, as this grows, We can apply some struct there later on.

I expect that this would be good enough for "P" entries: as such entries 
are used only by the biggest subsystems, I won't expect that the profiles 
list would be too big. 

If I'm wrong, though, changing its output is easy, as all the parsing
were done in separate: all we have to do would be to change this part.

-

Now, for the full MAINTAINERS content, I agree with you. I have
a patch series here which splits the parsing from the output,
which allows placing its contents inside a table and with a
filter javascript [1]. On my view, the output is a lot more
interesting for readers this way [2].
 
> Oh well, one can always hope.  Meanwhile, this seems useful, I've
> applied it.

Thanks!

---

[1] On such series, I'm creating a table with two rows:

        output += ".. _maintainers_table:\n\n"
        output += ".. flat-table::\n"
        output += "  :header-rows: 1\n\n"
        output += "  * - Subsystem\n"
        output += "    - Properties\n\n"

        self.state.document['maintainers_included'] = True

        for name, fields in maint_parser.maint_entries.items():
            output += f"  * - {name}\n"

            tag = "-"
            for field, lines in fields.items():
                field_name = maint_parser.fields.get(field, field)

                output += f"    {tag} :{field_name}:\n        "
                output += ",\n        ".join(lines) + "\n"
                tag = " "

            output += "\n"

   Which is a lot easier to read than the current output, and adding
   a small javascript that allows filtering entries, based at the
   contents of either subsystem or properties. That should help
   readers to seek for things they're interested.

   I considered ordering it by subsystems, and did some tests with that,
   but at the final version I ended removing.

   The main issue is that MAINTAINERS entries aren't grouped by
   subsystems. Also, we don't have any field to identify to what 
   subsystem each entry belongs.

   Using the mailing list field helps to have something close enough,
   while being fast. Even so, some caveats are needed, as:

   1) several entries contain multiple ML entries, which may include:
      - subsystem ML;
      - LKML;
      - driver-specific ML;
      - vendor-specific ML.

   2) several entries have only LKML.

   For the purpose of grouping such entries, even after filtering out LKML,
   due to (1), hints are needed to try to pick subsystem ML. Perhaps the
   best hint is to check if the entry is @kernel.org, which works reasonably
   well. Yet, not all subsystems have its ML there.

   I also considered sorting them by the number of files, using iglob 
   to calculate it. That would help to place the subsystem first, followed
   by subsystem drivers, and this is fast enough with my nvme disks but 
   this could slow kernel builds on mechanical HDs.

   So, I suspect that, if we want to have something more structured,
   the first step would be to do some rework at the MAINTAINERS file.

[2] I need some time to check if are there any regressions
    on the patch that splits the logic.

Regards,
Mauro