public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Miguel Ojeda <ojeda@kernel.org>
Cc: "Mauro Carvalho Chehab" <mchehab+huawei@kernel.org>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	rust-for-linux@vger.kernel.org,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Benno Lossin" <lossin@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Gary Guo" <gary@garyguo.net>, "Joe Perches" <joe@perches.com>,
	"Matteo Croce" <technoboy85@gmail.com>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Trevor Gross" <tmgross@umich.edu>
Subject: [PATCH 0/9] Improve process/maintainers output
Date: Mon,  4 May 2026 17:51:09 +0200	[thread overview]
Message-ID: <cover.1777908711.git.mchehab+huawei@kernel.org> (raw)

Hi Jon,

As promised, this series improve the output at process/maintainers:
instead of a pure enriched text, the maintainer's file content is
now converted with a table, and has gained a javascript to allow
filtering entries.

The initial patches change the logic to split parsing from
output generation. Now, everything is stored into a dict at
the parsing phase. This way, it is easier to adjust the
directive handler for it to produce a more structured document.

Right now, the entries are sorted alphabetically, per subsystem's
name.

---

As mentioned before, I did some extra tests here, changing the sort
logic:

- per mailing lists. Easy to do but require a couple of hints;
- per number of files (after using iglob) to calculate the
  actual number of patches. This is fast with NVME, but could
  be slow with HDD.

Doing that helps to group the output per subsytem (assuming
that each major subsystem has its own mailing list), and
placing the subsystem before each entry. Yet, after adding
the JS filter, I'm not sure if it is worth doing it(*).

So, I kept such changes out of the final version.

In any case, with the new logic, changing the output is easy.

(*) Hint: Try setting the <Filter:> box there to linux-doc :-D

    This one is sorted on a nice way, but if you set it to
    linux-media, you'll see that the first entry is Orphan.
    The most relevant one is hidden in the crowd.

-

It should also be easy to add some logic there at the Sphinx
directive to allow, for instance, include per-subsystem
entries, e.g. one could add, in the future, support for
things like:

	.. maintainers-include::
		mailing-list: linux-doc@vger.kernel.org
		sort-by: file-count

And have a page inside the subsystem (Documentation on this
example) with all maintainers per subsystem.

This is just a rough idea. I'm currently not planning to
implement it.


Matteo Croce (1):
  docs: escape ** glob pattern in MAINTAINERS descriptions

Mauro Carvalho Chehab (8):
  docs: maintainers_include: keep hidden TOC sorted
  docs: maintainers_include.py: split state machine on multiple funcs
  docs: maintainers_include: cleanup the code
  docs: maintainers_include.py: clean most SPHINXDIRS=process warnings
  docs: maintainers_include: do some coding style cleanups
  docs: maintainers_include: store maintainers entries on a dict
  docs: maintainers_include: don't ignore invalid profile entries
  docs: maintainers: add a filtering javascript

 Documentation/sphinx/maintainers_include.py | 405 ++++++++++++--------
 1 file changed, 249 insertions(+), 156 deletions(-)

-- 
2.54.0


             reply	other threads:[~2026-05-04 15:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04 15:51 Mauro Carvalho Chehab [this message]
2026-05-04 15:51 ` [PATCH 1/9] docs: maintainers_include: keep hidden TOC sorted Mauro Carvalho Chehab
2026-05-04 15:51 ` [PATCH 2/9] docs: escape ** glob pattern in MAINTAINERS descriptions Mauro Carvalho Chehab
2026-05-04 21:20   ` Randy Dunlap
2026-05-05  3:19     ` Joe Perches
2026-05-05  5:57       ` Mauro Carvalho Chehab
2026-05-05  6:46         ` Mauro Carvalho Chehab
2026-05-04 15:51 ` [PATCH 3/9] docs: maintainers_include.py: split state machine on multiple funcs Mauro Carvalho Chehab
2026-05-04 15:51 ` [PATCH 4/9] docs: maintainers_include: cleanup the code Mauro Carvalho Chehab
2026-05-04 15:51 ` [PATCH 5/9] docs: maintainers_include.py: clean most SPHINXDIRS=process warnings Mauro Carvalho Chehab
2026-05-04 15:51 ` [PATCH 6/9] docs: maintainers_include: do some coding style cleanups Mauro Carvalho Chehab
2026-05-04 15:51 ` [PATCH 7/9] docs: maintainers_include: store maintainers entries on a dict Mauro Carvalho Chehab
2026-05-04 15:51 ` [PATCH 8/9] docs: maintainers_include: don't ignore invalid profile entries Mauro Carvalho Chehab
2026-05-04 16:08   ` Miguel Ojeda
2026-05-04 20:26     ` Mauro Carvalho Chehab
2026-05-04 22:37       ` Gary Guo
2026-05-04 23:23         ` Mauro Carvalho Chehab
2026-05-05  0:25           ` Gary Guo
2026-05-04 23:34       ` Miguel Ojeda
2026-05-05  0:08         ` Mauro Carvalho Chehab
2026-05-05  0:20           ` Miguel Ojeda
2026-05-05  5:45             ` Mauro Carvalho Chehab
2026-05-05 11:16               ` Gary Guo
2026-05-05 13:09                 ` Mauro Carvalho Chehab
2026-05-05 14:37               ` Miguel Ojeda
2026-05-04 15:51 ` [PATCH 9/9] docs: maintainers: add a filtering javascript Mauro Carvalho Chehab
2026-05-04 21:12   ` Randy Dunlap
2026-05-05 13:00     ` Mauro Carvalho Chehab
2026-05-04 21:13 ` [PATCH 0/9] Improve process/maintainers output Randy Dunlap
2026-05-05 12:50   ` Mauro Carvalho Chehab

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=cover.1777908711.git.mchehab+huawei@kernel.org \
    --to=mchehab+huawei@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=joe@perches.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=technoboy85@gmail.com \
    --cc=tmgross@umich.edu \
    /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