From 0ff6a10fbd293a2361998832e393318ae4997116 Mon Sep 17 00:00:00 2001 From: Yuri Weinstein Date: Mon, 14 Apr 2025 07:41:13 -0700 Subject: [PATCH] doc: changed refs from quincy to squid Signed-off-by: Yuri Weinstein --- doc/dev/release-process.rst | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/doc/dev/release-process.rst b/doc/dev/release-process.rst index 97a504c065ee5..63185c2ec8700 100644 --- a/doc/dev/release-process.rst +++ b/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 `_, 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 `_, 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 `_, 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 `_ 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 git@github.com: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 `_ 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 `_ job will have already created and pushed the tag to ceph-releases.git. git remote add releases git@github.com: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 `_) -2. ceph.io Release Notes (e.g., `v15.2.17's ceph.io.git (www.ceph.io) PR `_) +1. ceph.git Release Notes (e.g., `v19.2.2's ceph.git (docs.ceph.com) PR `_) +2. ceph.io Release Notes (e.g., `v19.2.2's ceph.io.git (www.ceph.io) PR `_) 3. E-mail announcement See `the Ceph Tracker wiki page that explains how to write the release notes `_. -- 2.39.5