From: Jonathan Corbet <corbet@lwn.net>
To: Bagas Sanjaya <bagasdotme@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Documentation <linux-doc@vger.kernel.org>,
Linux ext4 <linux-ext4@vger.kernel.org>
Cc: Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
"Darrick J. Wong" <djwong@kernel.org>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Bagas Sanjaya <bagasdotme@gmail.com>
Subject: Re: [PATCH 0/4] Slurp (squash) ext4 subdocs
Date: Thu, 19 Jun 2025 13:56:48 -0600 [thread overview]
Message-ID: <87bjqjh5dr.fsf@trenco.lwn.net> (raw)
In-Reply-To: <20250618111544.22602-1-bagasdotme@gmail.com>
Bagas Sanjaya <bagasdotme@gmail.com> writes:
> When a doc is included by other doc via include:: directive, Sphinx will
> pick the included doc and parse it independently from the including doc
> regardless if it is listed in the docs toctree. This, however, can
> exposes duplicate label warning that refers the label to itself (bug?)
> when the label is placed before any section heading, since Sphinx
> encounters the label twice, both when parsing the included and the
> including docs.
>
> This could be solved by removing the problematic label. However, when it
> is heavily referenced by other doc (e.g. via :ref: directive), this can
> be a churn. Furthermore, the include:: usage pattern in kernel docs is
> to use it to included a common doc part that is shared by many docs
> (e.g. isonum.txt). ext4 docs, though, is the opposite: splitting docs
> into multiple reST files (subdocs) and including them in three master
> docs (overview.rst, globals.rst, and dynamic.rst)
>
> Let's slurp (squash) the subdocs instead. This will make the master docs
> larger of course (although not as big as KVM API docs), but one can use
> cross-reference labels without hitting aforementioned warning bug. Also,
> docs directory structure is tidier with only 4 files (master docs and
> about.rst). As a bonus, also reduce toctree depth as to not spill the
> whole hierarchy.
"slurp" is not exactly a technical term that will make sense to readers
of the changelogs.
But, more importantly... Might it be that the current file structure
reflects the way the authors wanted to manage the docs? It seems to me
that just organizing the existing files into a proper toctree would be
rather less churny and yield useful results, no?
jon
next prev parent reply other threads:[~2025-06-19 19:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 11:15 [PATCH 0/4] Slurp (squash) ext4 subdocs Bagas Sanjaya
2025-06-18 11:15 ` [PATCH 1/4] Documentation: ext4: Slurp included subdocs in high-level overview docs Bagas Sanjaya
2025-06-18 11:15 ` [PATCH 2/4] Documentation: ext4: Slurp included subdocs in global structures docs Bagas Sanjaya
2025-06-18 11:15 ` [PATCH 3/4] Documentation: ext4: Slurp included subdocs in dynamic " Bagas Sanjaya
2025-06-18 16:53 ` kernel test robot
2025-06-18 11:15 ` [PATCH 4/4] Documentation: ext4: Reduce toctree depth Bagas Sanjaya
2025-06-19 19:56 ` Jonathan Corbet [this message]
2025-06-20 3:24 ` [PATCH 0/4] Slurp (squash) ext4 subdocs 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=87bjqjh5dr.fsf@trenco.lwn.net \
--to=corbet@lwn.net \
--cc=adilger.kernel@dilger.ca \
--cc=bagasdotme@gmail.com \
--cc=djwong@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.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.