All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.