From 32d5e396d5d7a0ade7e73ea7e00b4a2f9dd75dcb Mon Sep 17 00:00:00 2001 From: Yusra AlSayyad Date: Wed, 5 Oct 2022 00:15:03 -0400 Subject: [PATCH] Update backport instructions to apply to any release - Remove interaction with DP0.2 - Use more obvious alias for release number --- work/backports.rst | 60 ++++++++++++++++++++-------------------------- 1 file changed, 26 insertions(+), 34 deletions(-) diff --git a/work/backports.rst b/work/backports.rst index b235979d..ae32d2b9 100644 --- a/work/backports.rst +++ b/work/backports.rst @@ -2,47 +2,48 @@ Backporting Tickets to a Release Branch ####################################### -So you have a ticket that you think should be backported to ``v23.0.0`` and/or be used for DP0.2. -What next? +So you have a ticket that you think should be backported to the release branch? What next? +Note, these instructions use v88 as an alias for the release of the science pipelines to backport to. +Replace the 88 with 24, 27, or whatever major release number we are on now. -1) First, add the label "backport-v23" to your jira ticket. +1) First, add the label "backport-v88" to your jira ticket. - This will flag it for review by the DM-CCB or the DP0.2 campaign managers. + This will flag it for review by the DM-CCB. Continue merging your ticket to the default branch (``main``) and mark the ticket ``Done`` per instructions in the normal :doc:`flow`. -2) Wait for approval. The ticket will gain the label "backport-approved." A comment will be posted on the ticket that you may start the backporting process. +2) Wait for approval. The ticket will gain the label "backport-approved." -3) Checkout the release branch, ``v23.0.x``, for each repo affected by your ticket. +3) Checkout the release branch, ``v88.0.x``, for each repo affected by your ticket. .. code-block:: bash - git checkout v23.0.x + git checkout v88.0.x - If the repo does not already have a ``v23.0.x`` branch, you need to create one based on ``v23.0.0.rc1`` (not the latest rcN, although that should be identical): + If the repo does not already have a ``v88.0.x`` branch, you need to create one based on ``v88.0.0.rc1`` (not the latest rcN, although that should be identical): .. code-block:: bash - git checkout v23.0.0.rc1 - git checkout -b v23.0.x - git push -u origin v23.0.x + git checkout v88.0.0.rc1 + git checkout -b v88.0.x + git push -u origin v88.0.x - Now treat ``v23.0.x`` same as you would the default branch (``main``). + Now treat ``v88.0.x`` same as you would the default branch (``main``). -4) Create a copy of your ticket branch called ``tickets/DM-XXXXX-v23``. +4) Create a copy of your ticket branch called ``tickets/DM-XXXXX-v88``. .. code-block:: bash git checkout tickets/DM-XXXXX - git checkout -b tickets/DM-XXXXX-v23 - git rebase --onto v23.0.x + git checkout -b tickets/DM-XXXXX-v88 + git rebase --onto v88.0.x In a new clone, this branch may not exist anymore if you have already merged your PR because merged branches may be automatically deleted. - In this case, you can branch ``tickets/DM-XXXXX-v23`` from ``v23.0.x``, and cherry-pick the ticket commits. + In this case, you can branch ``tickets/DM-XXXXX-v88`` from ``v88.0.x``, and cherry-pick the ticket commits. .. code-block:: bash - git checkout v23.0.x - git checkout -b tickets/DM-XXXXX-v23 + git checkout v88.0.x + git checkout -b tickets/DM-XXXXX-v88 git cherry-pick The following may help you find your hash[es] from ``main``: @@ -50,33 +51,24 @@ What next? 5) Resolve any rebase or cherry-pick problems depending on your method. Continue using the same procedure outlined in :ref:`review-preparation`. - Check that it cleanly builds via scons. There should be a latest shared v23.0.0.rcN stack on lsst-devl. + Check that it cleanly builds via scons. There should be a latest shared v88.0.0.rcN stack on the development cluster. Run Jenkins. When running Jenkins, build against the release branch and rc1 even if later rcNs exist. - The default ``SPLENV_REF`` may no longer be appropriate for ``v23.0.x``. + The default ``SPLENV_REF`` may no longer be appropriate for ``v88.0.x``. If you are unsure of the recommended env for the release, check with the release manager. .. code-block:: bash - REFS: tickets/DM-XXXXX-v23 v23.0.x v23.0.0.rc1 + REFS: tickets/DM-XXXXX-v88 v88.0.x v88.0.0.rc1 PRODUCTS: lsst_distrib lsst_ci ci_imsim ci_hsc - SPLENV_REF: 0.8.0 + SPLENV_REF: You may find that the ticket cannot be cleanly backported without first backporting another ticket. -6) When it passes, merge to ``v23.0.x`` using the same procedure outlined in :ref:`workflow-code-review-merge`, +6) When it passes, merge to ``v88.0.x`` using the same procedure outlined in :ref:`workflow-code-review-merge`, including creating a pull request. - On your pull request, remember to change the base branch to ``v23.0.x``. + On your pull request, remember to change the base branch to ``v88.0.x``. If the backport was clean, you may self-review. If the backport was not clean and you would like another pair of eyes, you may ask someone to hit the "Approved" button on GitHub, but please *do not* put your ticket status back into ``In Review`` on Jira. -7) When merged to ``v23.0.x``, label your Jira ticket ``backport-done``. - - -Interaction between v23 and DP0.2 ---------------------------------- -Before the full-scale data release processing of step1 commences for DP0.2, a new rcN release will be built on approximately weekly cadence. -This weekly cadence follows the weekly review of backport requests. - -After step1 begins and 23.0.0 is released, the current plan is to increment the release versions. -This backporting process will remain the same, but with evolving release tags and release branch numbers. +7) When merged to ``v88.0.x``, label your Jira ticket ``backport-done``.