Merge pull request ceph#62807 from ceph/wip-yuriw-release.pocess-main

doc: changed refs from quincy to squid

Reviewed-by: Anthony D'Atri <[email protected]>

Author: yuriw

doc/dev/release-process.rst

@@ -27,7 +27,7 @@ For each new major (alphabetical) release, you must create one ``ceph-release``
 Summarized build process
 ========================
 
-1. QE finishes testing and finds a stopping point.  That commit is pushed to the ``$release-release`` branch in ceph.git (e.g., ``quincy-release``).  This allows work to continue in the working ``$release`` branch without having to freeze it during the release process.
+1. QE finishes testing and finds a stopping point.  That commit is pushed to the ``$release-release`` branch in ceph.git (e.g., ``squid-release``).  This allows work to continue in the working ``$release`` branch without having to freeze it during the release process.
 2. The Ceph Council approves and notifies the "Build Lead".
 3. The "Build Lead" starts the `Jenkins multijob <https://jenkins.ceph.com/view/all/job/ceph>`_, which triggers all builds.
 4. Packages are pushed to chacra.ceph.com.
@@ -44,13 +44,13 @@ Hotfix Release Process Deviation
 
 A hotfix release has a couple differences.
 
-1. Check out the most recent tag. For example, if we're releasing a hotfix on top of 17.2.3, ``git checkout -f -B quincy-release tags/v17.2.3``.
+1. Check out the most recent tag. For example, if we're releasing a hotfix on top of 19.2.1, ``git checkout -f -B squid-release tags/v19.2.1``.
 2. ``git cherry-pick -x`` the necessary hotfix commits (Note: only "cherry-pick" must be used).
-3. ``git push -f origin quincy-release``.
+3. ``git push -f origin squid-release``.
 4. Verify the commits in the ``$release-release`` branch:
 
-   1. To check against the previous point release (if we are making 17.2.4, this would be 17.2.3), run ``git log --pretty=oneline --no-merges tags/v17.2.3..origin/quincy-release``. Verify that the commits produced are exactly what we want in the next point release.
-   2. To check against the RC in the "ceph-ci" repo (``ceph-ci`` in this example), run ``git log --pretty=oneline --no-merges origin/quincy-release...ceph-ci/quincy-release``. There should be no output produced if the ``$release-release`` branch in the ceph repo is identical to the RC in ``ceph-ci``. Note the use of git `triple dot notation <https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection>`_, which shows any commit discrepencies between both references.
+   1. To check against the previous point release (if we are making 19.2.2, this would be 19.2.1), run ``git log --pretty=oneline --no-merges tags/v19.2.1..origin/squid-release``. Verify that the commits produced are exactly what we want in the next point release.
+   2. To check against the RC in the "ceph-ci" repo (``ceph-ci`` in this example), run ``git log --pretty=oneline --no-merges origin/squid-release...ceph-ci/squid-release``. There should be no output produced if the ``$release-release`` branch in the ceph repo is identical to the RC in ``ceph-ci``. Note the use of git `triple dot notation <https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection>`_, which shows any commit discrepencies between both references.
 5. Notify the "Build Lead" to start the build.
 6. The "Build Lead" should set ``RELEASE_TYPE=HOTFIX`` instead of ``STABLE``.
 
@@ -60,37 +60,37 @@ Security Release Process Deviation
 A security/CVE release is similar to a hotfix release with two differences:
 
     1. The fix should be pushed to the `ceph-private <https://github.com/ceph/ceph-private>`_ repo instead of ceph.git (requires GitHub Admin Role).
-    2. The tags (e.g., v17.2.4) must be manually pushed to ceph.git by the "Build Lead."
+    2. The tags (e.g., v19.2.3) must be manually pushed to ceph.git by the "Build Lead."
 
-1. Check out the most recent tag. For example, if we're releasing a security fix on top of 17.2.3, ``git checkout -f -B quincy-release origin/v17.2.3``
+1. Check out the most recent tag. For example, if we're releasing a security fix on top of 19.2.2, ``git checkout -f -B squid-release origin/v19.2.2``
 2. ``git cherry-pick -x`` the necessary security fix commits
 3. ``git remote add security [email protected]:ceph/ceph-private.git``
-4. ``git push -f security quincy-release``
+4. ``git push -f security squid-release``
 5. Notify the "Build Lead" to start the build.
 6. The "Build Lead" should set ``RELEASE_TYPE=SECURITY`` instead of ``STABLE``.
 7. Finally, the `ceph-tag <https://github.com/ceph/ceph-build/blob/main/ansible/roles/ceph-release/tasks/push.yml>`_ steps need to be manually run by the "Build Lead" as close to the Announcement time as possible::
 
-    # Example using quincy pretending 17.2.4 is the security release version
+    # Example using squid pretending 19.2.3 is the security release version
     # Add the ceph-releases repo (also requires GitHub Admin Role). The `ceph-setup <https://jenkins.ceph.com/job/ceph-setup>`_ job will have already created and pushed the tag to ceph-releases.git.
     git remote add releases [email protected]:ceph/ceph-releases.git
     git fetch --all
     # Check out the version commit
-    git checkout -f -B quincy-release releases/quincy-release
-    git push -f origin quincy-release
-    git push origin v17.2.4
-    # Now create a Pull Request of quincy-release targeting quincy to merge the version commit and security fixes back into the quincy branch
+    git checkout -f -B squid-release releases/squid-release
+    git push -f origin squid-release
+    git push origin v19.2.3
+    # Now create a Pull Request of squid-release targeting squid to merge the version commit and security fixes back into the squid branch
 
 1. Preparing the release branch
 ===============================
 
-Once QE has determined a stopping point in the working (e.g., ``quincy``) branch, that commit should be pushed to the corresponding ``quincy-release`` branch.
+Once QE has determined a stopping point in the working (e.g., ``squid``) branch, that commit should be pushed to the corresponding ``squid-release`` branch.
 
 Notify the "Build Lead" that the release branch is ready.
 
 2. Starting the build
 =====================
 
-We'll use a stable/regular 15.2.17 release of Octopus as an example throughout this document.
+We'll use a stable/regular 19.2.2 release of Squid as an example throughout this document.
 
 1. Browse to https://jenkins.ceph.com/view/all/job/ceph/build?delay=0sec
 2. Log in with GitHub OAuth
@@ -125,8 +125,8 @@ NOTE: if for some reason the build has to be restarted (for example if one distr
 
 Packages take hours to build. Use those hours to create the Release Notes and Announcements:
 
-1. ceph.git Release Notes (e.g., `v15.2.17's ceph.git (docs.ceph.com) PR <https://github.com/ceph/ceph/pull/47198>`_)
-2. ceph.io Release Notes (e.g., `v15.2.17's ceph.io.git (www.ceph.io) PR <https://github.com/ceph/ceph.io/pull/427>`_)
+1. ceph.git Release Notes (e.g., `v19.2.2's ceph.git (docs.ceph.com) PR <https://github.com/ceph/ceph/pull/62734>`_)
+2. ceph.io Release Notes (e.g., `v19.2.2's ceph.io.git (www.ceph.io) PR <https://github.com/ceph/ceph.io/pull/864>`_)
 3. E-mail announcement
 
 See `the Ceph Tracker wiki page that explains how to write the release notes <https://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO_write_the_release_notes>`_.