Linux Documentation
 help / color / mirror / Atom feed
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

  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