[libc-commits] [libc] [llvm] [docs] Remove all references to Maintainers.rst (PR #200368)

[David Spickett via libc-commits]

https://github.com/DavidSpickett created https://github.com/llvm/llvm-project/pull/200368

All projects are using Maintainers.md files now.

>From 490d353e134aae6238e49962a8fe49d15b35f8e9 Mon Sep 17 00:00:00 2001
From: David Spickett <david.spickett at arm.com>
Date: Fri, 29 May 2026 11:09:49 +0100
Subject: [PATCH] [docs] Remove all references to Maintainers.rst

All projects are using Maintainers.md files now.
---
 libc/docs/porting.rst         | 2 +-
 llvm/docs/Contributing.rst    | 4 ++--
 llvm/docs/DeveloperPolicy.rst | 9 ++++-----
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/libc/docs/porting.rst b/libc/docs/porting.rst
index 98e1da47273e3..5ac1191c75cea 100644
--- a/libc/docs/porting.rst
+++ b/libc/docs/porting.rst
@@ -95,7 +95,7 @@ people are the maintainers, and they are responsible for keeping their target in
 good shape. This means fixing their target when it breaks, reviewing patches
 related to their target, and keeping the target's CI running.
 
-Maintainers are listed in libc/maintainers.rst and must follow
+Maintainers are listed in libc/maintainers.md and must follow
 `LLVM's maintainer policy <https://llvm.org/docs/DeveloperPolicy.html#maintainers>`_.
 
 CI builders
diff --git a/llvm/docs/Contributing.rst b/llvm/docs/Contributing.rst
index 817fc138fe2c0..b6475e2f6c3a7 100644
--- a/llvm/docs/Contributing.rst
+++ b/llvm/docs/Contributing.rst
@@ -116,9 +116,9 @@ and add them to your patch when requesting a review.
 
 Suitable reviewers are the maintainers of the project you are modifying, and
 anyone else working in the area your patch touches. To find maintainers, look for
-the ``Maintainers.md`` or ``Maintainers.rst`` file in the root of the project's
+the ``Maintainers.md`` file in the root of the project's
 sub-directory. For example, LLVM's is ``llvm/Maintainers.md`` and
-clang-tools-extra's is ``clang-tools-extra/Maintainers.rst``.
+clang-tools-extra's is ``clang-tools-extra/Maintainers.md``.
 
 If you are a new contributor, you will not be able to select reviewers in such a
 way, in which case you can still get the attention of potential reviewers by CC'ing
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index a99a6d0090c5e..e302b2d79dc1b 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -141,8 +141,7 @@ products.
 Maintainers are those volunteers; they are regular contributors who volunteer
 to take on additional community responsibilities beyond code contributions.
 Community members can find active and inactive maintainers for a project in the
-``Maintainers.md`` or ``Maintainers.rst`` file at the root directory of the
-individual project.
+``Maintainers.md`` file at the root directory of the individual project.
 
 Maintainers are volunteering to take on the following shared responsibilities
 within an area of a project:
@@ -192,7 +191,7 @@ the same project vouches for their ability to perform the responsibilities and
 there are no explicit objections raised by the community.
 
 *To step down as a maintainer*, you can move your name to the "inactive
-maintainers" section of the ``Maintainers.md`` or ``Maintainers.rst`` file for
+maintainers" section of the ``Maintainers.md`` file for
 the project, or remove your name entirely; no PR review is necessary.
 Additionally, any maintainer who has not been actively performing their
 responsibilities over an extended period of time can be moved to the "inactive
@@ -207,8 +206,8 @@ as a maintainer is normal and does not prevent someone from resuming their
 activities as a maintainer in the future.
 
 *To resume activities as a maintainer*, you can post a PR moving your name from
-the "inactive maintainers" section of the ``Maintainers.md`` or
-``Maintainers.rst``file to the active maintainers list. Because the volunteer
+the "inactive maintainers" section of the ``Maintainers.md``
+file to the active maintainers list. Because the volunteer
 was already previously accepted, they will be re-accepted so long as at least
 one maintainer in the same project approves the PR and there are no explicit
 objections raised by the community.