From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: "Gary Guo" <gary@garyguo.net>, "Benno Lossin" <lossin@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Linux Doc Mailing List" <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>,
"Boqun Feng" <boqun@kernel.org>,
"Danilo Krummrich" <dakr@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>
Subject: Re: [PATCH v2 11/11] MAINTAINERS: use a URL for pin-init maintainer's profile entry
Date: Fri, 8 May 2026 09:16:44 +0200 [thread overview]
Message-ID: <20260508091644.420bd440@foz.lan> (raw)
In-Reply-To: <CANiq72kN=2RsE0Wm_489Sc-VKO40A0uYinCj1McT=YMu=cM4aQ@mail.gmail.com>
On Wed, 6 May 2026 10:38:07 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> On Wed, May 6, 2026 at 8:49 AM Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> >
> > Maybe it is just me, but placing doc files in the crowd together with code
> > on a project where documentation has its own directory sounds weird(*).
> >
> > (*) except for userspace tools and staging drivers where we want
> > everything, including documentation, contained on a single place.
>
> It is a similar case -- they are vendored libraries developed and used
> elsewhere (e.g. in userspace too).
I see.
> > As you're already using some scripting to do a bidirectional sync,
> > you could add there some logic to convert rust pin-init documentation
> > to rst and place it at Documentation/rust/.
>
> Most of the pin-init documentation is elsewhere (embedded in the Rust
> source code) and already rendered at rust.docs.kernel.org.
>
> (Using Sphinx for Rust has been discussed in the list a few times in
> the past too, and that has its own set of constraints).
>
> > Btw, on a quick check, only Rust has markdown files:
> >
> > $ git ls-files|grep ".md$"|grep -v tools/
> > rust/pin-init/CONTRIBUTING.md
> > rust/pin-init/README.md
> > rust/proc-macro2/README.md
> > rust/quote/README.md
> > rust/syn/README.md
> >
> > As one of the people who spent years helping improving the Kernel
> > documentation and doing lots of conversions from markdown
> > and other non-structured text formats to RST, I have to say that I'm
> > concerned with any trends that would add doc files that aren't
> > properly integrated with the Kernel documentation system like those.
>
> All those are vendored libraries, and most of those `README.md` files
> are about clarifying where they are taken from and their licensing,
> e.g.
>
> # `quote`
>
> These source files come from the Rust `quote` crate, version 1.0.40
> (released 2025-03-12), hosted in the <https://github.com/dtolnay/quote>
> repository, licensed under "Apache-2.0 OR MIT" and only modified to add
> the SPDX license identifiers.
>
> For copyright details, please see:
>
> https://github.com/dtolnay/quote/blob/1.0.40/README.md#license
> https://github.com/dtolnay/quote/blob/1.0.40/LICENSE-APACHE
> https://github.com/dtolnay/quote/blob/1.0.40/LICENSE-MIT
Just my two cents, but all license files that are applies to the Kernel
are already under LICENSES/ directory, and there is a document defining
how SPDX and LICENSES should be used:
Documentation/process/license-rules.rst.
IMO it would make more sense to point to the corresponding LICENSES/ files.
>
> i.e. they are not intended to be kernel documentation, and moving them
> away from the source files doesn't sound like an improvement,
> especially since we were explicitly requested to make the provenance
> very clear.
In this case, this sounds OK.
> We could perhaps have a list of vendored libraries in
> Documentation/rust/vendored-libraries.rst` -- that could perhaps be
> useful for some folks.
Makes sense to me.
> In any case, I understand your desire to keep things integrated in the
> kernel documentation, and I appreciate that (I also like to have
> everything neatly integrated), but please do not assume we have been
> randomly adding Markdown for no reason or that we are not trying to
> keep things properly integrated... :(
I didn't intend to imply that tose aren't properly integrated. It is
just that it raised my eyebrows seeing more doc-like files over there.
---
With regards to patch 11/11, I'll send a new version just changing
the "P" tag without dropping the .md file.
Thanks,
Mauro
next prev parent reply other threads:[~2026-05-08 7:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 13:25 [PATCH v2 00/11] Improve process/maintainers output Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 01/11] docs: maintainers_include: keep hidden TOC sorted Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 02/11] docs: maintainers_include: split state machine on multiple funcs Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 03/11] docs: maintainers_include: cleanup the code Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 04/11] docs: maintainers_include: clean most SPHINXDIRS=process warnings Mauro Carvalho Chehab
2026-05-05 19:53 ` Randy Dunlap
2026-05-08 6:32 ` Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 05/11] docs: maintainers_include: do some coding style cleanups Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 06/11] docs: maintainers_include: store maintainers entries on a dict Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 07/11] docs: maintainers_include: properly handle file patterns Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 08/11] docs: maintainers_include: add a filtering javascript Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 09/11] docs: maintainers_include: don't ignore invalid profile entries Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 10/11] MAINTAINERS: make clearer about what's expected for "P" field Mauro Carvalho Chehab
2026-05-05 18:02 ` Miguel Ojeda
2026-05-08 6:42 ` Mauro Carvalho Chehab
2026-05-05 13:25 ` [PATCH v2 11/11] MAINTAINERS: use a URL for pin-init maintainer's profile entry Mauro Carvalho Chehab
2026-05-05 13:49 ` Gary Guo
2026-05-05 18:04 ` Miguel Ojeda
2026-05-06 6:49 ` Mauro Carvalho Chehab
2026-05-06 8:38 ` Miguel Ojeda
2026-05-08 7:16 ` Mauro Carvalho Chehab [this message]
2026-05-08 9:45 ` Miguel Ojeda
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=20260508091644.420bd440@foz.lan \
--to=mchehab+huawei@kernel.org \
--cc=a.hindborg@kernel.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=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--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