From: "Rito Rhymes" <rito@ritovision.com>
To: "Jonathan Corbet" <corbet@lwn.net>,
"Rito Rhymes" <rito@ritovision.com>, <linux-doc@vger.kernel.org>
Cc: "Shuah Khan" <skhan@linuxfoundation.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] docs: set canonical base URL for HTML output
Date: Mon, 23 Mar 2026 14:03:23 -0400 [thread overview]
Message-ID: <DHACYJK8P7RN.MUHEBN0UC0LK@ritovision.com> (raw)
In-Reply-To: <87zf3zd2cs.fsf@trenco.lwn.net>
This is about protecting source authority in indexed search results,
which Linux kernel documentation very much exists in already.
Linux protects its trademarks, uses official marks and domains to
distinguish the project’s identity from copies and forks, and uses
provenance mechanisms such as sigstore for verifying the origin and
authenticity of software artifacts. A canonical URL is a different
angle to cover.
Indexed search results are an important distribution surface for
documentation, and it is also a hostile environment. For a
project like the Linux kernel, where its material is widely
copied, mirrored, archived, rehosted, and referenced across many
alternate paths and contexts, the stakes are higher and
protecting source authority matters more. Given the other ways
Linux already protects project identity, canonical URLs are a
small low-cost measure that supports its source authority for
indexing providers by indicating the preferred official URL for
a given resource.
The documentation site appears agnostic toward search engine
indexing because it neither opts out of indexed search for
compliant crawlers nor explicitly adds directives aimed at
optimizing for it. By being on the open web and not opting out,
it by default participates in the indexed web as a valid and standard
distribution surface for documentation. In that context, if
the site is part of the indexed web whether or not it actively
courts it, then using a low-cost standard signal like a canonical
URL is simply part of managing that reality responsibly.
> ...and how does it help all of the people who do their
> own docs builds?
You accepted the favicon fix earlier but you could argue something
similar about it:
"After someone downloads the Linux repo and runs the documentation
site locally, how does having the little logo visible in the browser
help them? Without it, will they not know they are viewing the Linux
documentation site?"
They are clearly different but what's in common is that they're
low-cost signals supporting the Linux identity on the web.
Rito
next prev parent reply other threads:[~2026-03-23 18:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 12:49 [PATCH] docs: set canonical base URL for HTML output Rito Rhymes
2026-03-22 20:40 ` Jonathan Corbet
2026-03-23 18:03 ` Rito Rhymes [this message]
2026-03-23 18:26 ` Jonathan Corbet
2026-03-23 19:09 ` Rito Rhymes
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=DHACYJK8P7RN.MUHEBN0UC0LK@ritovision.com \
--to=rito@ritovision.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
/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