All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vernet <void@manifault.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>,
	Linux BPF <bpf@vger.kernel.org>,
	Linux Documentation <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Tobin C. Harding" <me@tobin.cc>
Subject: Re: [PATCH bpf-next] bpf, doc: use internal linking for link to netdev FAQ
Date: Mon, 13 Mar 2023 08:56:38 -0500	[thread overview]
Message-ID: <20230313135638.GD2392@maniforge> (raw)
In-Reply-To: <87wn3kvkkq.fsf@meer.lwn.net>

On Mon, Mar 13, 2023 at 07:37:25AM -0600, Jonathan Corbet wrote:
> David Vernet <void@manifault.com> writes:
> 
> > Sure, but there are practicalities to consider here. It takes O(minutes)
> > to do a full docs build, as opposed to O(seconds). I've done reviews of
> > docs patches where the engineer tried to build the docs tree, but
> > thought it was hung and ended up cancelling it. Full docs builds also
> > unfortunately spew quite a few warnings in other subtrees. You have to
> > carefully wade through the warnings in those other subtrees to ensure
> > you haven't added any new ones.
> >
> > It's hard enough to get people to write documentation. It's also hard
> > enough to get them to test building their documentation before
> > submitting it. I think there is a lot of value in being able to build
> > the documentation for the subtree you're contributing to, and be able to
> > have some expectation that it builds cleanly. Let's not make it more
> > difficult for the people who are actually adding substantive
> > documentation.
> 
> I get your point, but that is essentially saying that there should be no
> linkages between our documentation subtrees, which defeats much of the
> purpose of using a system like Sphinx.

I certainly agree that inter-subtree links are great to have, though in
my opinion, other features such as linking kernel-doc comments, auto
section labeling, etc make Sphinx very useful in their own right. But
yes, having inter-subtree links is of course a useful feature as well.

> In this specific case, though, there is a better solution.  Text like:
> 
>   see the netdev FAQ (Documentation/process/maintainer-netdev.rst)
> 
> will add links in the built docs, and also tells readers of the
> plain-text files where they should be looking.  Without adding warnings.

Nice, seems like the best of both worlds. A syntax clarification
question: are you saying that this would work?

> see the `netdev-FAQ`_.
>
>   <snip>
>
> .. _netdev-FAQ: Documentation/process/maintainer-netdev.rst

Or is it required to have the full path inline in the text, as in your
example:

>   see the netdev FAQ (Documentation/process/maintainer-netdev.rst)

The benefit of the former is of course that you only have to specify the
link in one place.

> For the bigger problem, the right answer is to start using intersphinx.
> I guess I need to get serious about playing with that.

Based on a quick online search, that indeed sounds like the ideal
solution.

Thanks,
David

  reply	other threads:[~2023-03-13 13:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-13  2:51 [PATCH bpf-next] bpf, doc: use internal linking for link to netdev FAQ Bagas Sanjaya
2023-03-13  3:09 ` David Vernet
2023-03-13  4:20   ` Bagas Sanjaya
2023-03-13  4:42     ` Bagas Sanjaya
2023-03-13  7:57       ` Bagas Sanjaya
2023-03-13 12:36         ` David Vernet
2023-03-13 13:37           ` Jonathan Corbet
2023-03-13 13:56             ` David Vernet [this message]
2023-03-13 14:27               ` Jonathan Corbet
2023-03-13 14:32                 ` David Vernet
2023-03-14  3:28                   ` Bagas Sanjaya
2023-03-14  3:25             ` Bagas Sanjaya

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=20230313135638.GD2392@maniforge \
    --to=void@manifault.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bagasdotme@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=me@tobin.cc \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yhs@fb.com \
    /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.