[llvm] [llvm][docs] Minor fixes and improvements for release process (PR #151956)

Mon Oct 6 01:49:33 PDT 2025

https://github.com/c-rhodes updated https://github.com/llvm/llvm-project/pull/151956

>From 99dc76eb2fb183432a1fc9aaa7999e4b22fae98e Mon Sep 17 00:00:00 2001
From: Cullen Rhodes <cullen.rhodes at arm.com>
Date: Mon, 4 Aug 2025 08:27:04 +0000
Subject: [PATCH 1/2] [llvm][docs] Minor fixes and improvements for release
 process

- The list numbering in [1] currently starts again after item 3 due to
  the code-block.
- Remove mentions of Phabricator and Subversion.
- In final step of [2] remove mention of
  llvm/utils/git/sync-release-repo.sh, which was removed in #73682.
- Add direct links to:
  - www-releases repo.
  - backporting doc [3].
  - Getting Started page.
  - RELEASE_TESTERS.txt.
  - Release Sources GitHub workflow.

[1] https://llvm.org/docs/HowToReleaseLLVM.html#create-release-branch
[2] https://llvm.org/docs/HowToReleaseLLVM.html#triaging-bug-reports-for-releases
[3] https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches
---
 llvm/docs/HowToReleaseLLVM.rst | 53 +++++++++++++++-------------------
 1 file changed, 24 insertions(+), 29 deletions(-)

diff --git a/llvm/docs/HowToReleaseLLVM.rst b/llvm/docs/HowToReleaseLLVM.rst
index f3792e367de0d..eb7a7feae4d2e 100644
--- a/llvm/docs/HowToReleaseLLVM.rst
+++ b/llvm/docs/HowToReleaseLLVM.rst
@@ -116,11 +116,9 @@ Branch the Git trunk using the following procedure:
 
 #. Bump the version in trunk to N.0.0git with the script in
    ``llvm/utils/release/bump-version.py``, and tag the commit with llvmorg-N-init.
-   If ``X`` is the version to be released, then ``N`` is ``X + 1``.
+   If ``X`` is the version to be released, then ``N`` is ``X + 1``. ::
 
-::
-
-  $ git tag -sa llvmorg-N-init
+    $ git tag -sa llvmorg-N-init
 
 4. Clear the release notes in trunk with the script in
    ``llvm/utils/release/clear-release-notes.py``.
@@ -145,10 +143,12 @@ Tag release candidates:
   $ git tag -sa llvmorg-X.Y.Z-rcN
 
 The pre-packaged source tarballs will be automatically generated via the
-"Release Sources" workflow on GitHub.  This workflow will create an artifact
-containing all the release tarballs and the artifact attestation.  The
-Release Manager should download the artifact, verify the tarballs, sign them,
-and then upload them to the release page.
+`Release Sources
+<https://github.com/llvm/llvm-project/actions/workflows/release-sources.yml>`_
+workflow on GitHub.  This workflow will create an artifact containing all the
+release tarballs and the artifact attestation.  The Release Manager should
+download the artifact, verify the tarballs, sign them, and then upload them to
+the release page.
 
 ::
 
@@ -217,8 +217,9 @@ consistently validated and released binaries for their targets/OSs. To contact
 them, you should post on the `Discourse forums (Project
 Infrastructure - Release Testers). <https://discourse.llvm.org/c/infrastructure/release-testers/66>`_
 
-The official testers list is in the file ``RELEASE_TESTERS.TXT``, in the ``LLVM``
-repository.
+The official testers list is in the file `RELEASE_TESTERS.TXT
+<https://github.com/llvm/llvm-project/blob/main/llvm/RELEASE_TESTERS.TXT>`_, in
+the LLVM repository.
 
 Community Testing
 -----------------
@@ -276,7 +277,8 @@ from the Milestone. Debugging can continue, but on trunk.
 Backport Requests
 -----------------
 
-Instructions for requesting a backport to a stable branch can be found :doc:`here <GitHub>`.
+Instructions for requesting a backport to a stable branch can be found
+:ref:`here <backporting>`.
 
 Triaging Bug Reports for Releases
 ---------------------------------
@@ -301,26 +303,19 @@ This section describes how to triage bug reports:
    using the /cherry-pick or /branch comments if this has not been done already.
 
 #. If a bug has been fixed and has a pull request created for backporting it,
-   then update its status to "Needs Review" and notify a knowledgeable reviewer.
-   Usually you will want to notify the person who approved the patch in Phabricator,
-   but you may use your best judgement on who a good reviewer would be.  Once
-   you have identified the reviewer(s), assign the issue to them and mention
-   them (i.e @username) in a comment and ask them if the patch is safe to backport.
-   You should also review the bug yourself to ensure that it meets the requirements
-   for committing to the release branch.
+   then update its status to "Needs Review" and notify a knowledgeable
+   reviewer.  Usually you will want to notify the person who approved the
+   patch, but you may use your best judgement on who a good reviewer would be.
+   Once you have identified the reviewer(s), assign the issue to them and
+   mention them (i.e @username) in a comment and ask them if the patch is safe
+   to backport.  You should also review the bug yourself to ensure that it
+   meets the requirements for committing to the release branch.
 
 #. Once a bug has been reviewed, add the release:reviewed label and update the
    issue's status to "Needs Merge".  Check the pull request associated with the
    issue.  If all the tests pass, then the pull request can be merged.  If not,
    then add a comment on the issue asking someone to take a look at the failures.
 
-#. Once the pull request has been merged push it to the official release branch
-   with the script ``llvm/utils/git/sync-release-repo.sh``.
-
-   Then add a comment to the issue stating that the fix has been merged along with
-   the git hashes from the release branch.  Add the release:merged label to the issue
-   and close it.
-
 
 Release Patch Rules
 -------------------
@@ -364,9 +359,8 @@ Update Documentation
 Review the documentation in the release branch and ensure that it is up
 to date.  The "Release Notes" must be updated to reflect new features, bug
 fixes, new known issues, and changes in the list of supported platforms.
-The "Getting Started Guide" should be updated to reflect the new release
-version number tag available from Subversion and changes in basic system
-requirements.
+The :doc:`GettingStarted` page should be updated to reflect the new release
+version number tag and changes in basic system requirements.
 
 .. _tag:
 
@@ -386,7 +380,8 @@ Update the LLVM Website
 The website must be updated before the release announcement is sent out.  Here
 is what to do:
 
-#. Check out the ``www-releases`` module from GitHub.
+#. Check out the `www-releases <https://github.com/llvm/www-releases>`_ repo
+   from GitHub.
 
 #. Create a new sub-directory ``X.Y.Z`` in the releases directory.
 

>From 3787932b1d9f93204c507e6ac8236de99a8225f8 Mon Sep 17 00:00:00 2001
From: Cullen Rhodes <cullen.rhodes at arm.com>
Date: Mon, 6 Oct 2025 08:40:43 +0000
Subject: [PATCH 2/2] fix after most recent change

---
 llvm/docs/HowToReleaseLLVM.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/llvm/docs/HowToReleaseLLVM.rst b/llvm/docs/HowToReleaseLLVM.rst
index eb7a7feae4d2e..1795d3a81ce95 100644
--- a/llvm/docs/HowToReleaseLLVM.rst
+++ b/llvm/docs/HowToReleaseLLVM.rst
@@ -120,7 +120,7 @@ Branch the Git trunk using the following procedure:
 
     $ git tag -sa llvmorg-N-init
 
-4. Clear the release notes in trunk with the script in
+#. Clear the release notes in trunk with the script in
    ``llvm/utils/release/clear-release-notes.py``.
 
 #. Create the release branch from the last known good revision from before the

