Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions work/backports.rst
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,11 @@ What next?

Now treat ``v23.0.x`` same as you would the default branch (``main``).

.. note::

If the release branch and the parent commit for this backport request are at the same commit, you do not need cherry pick commits onto the release branch and can instead fast forward the release branch.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly don't know how to judge this PR or this statement.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could instead say, "if the release branch (or if it doesn't exist, the release tags) are on a commit that is also on the main branch and your ticket is the first one after that commit". A screenshot of this condition in some git GUI would really be worth a thousand variations of those words, though.

If this is the case, at this point in the process jump to the `instructions below <backports-fast-forward>`.

4) Create a copy of your ticket branch called ``tickets/DM-XXXXX-v23``.

.. code-block:: bash
Expand Down Expand Up @@ -75,3 +80,33 @@ What next?
but please *do not* put your ticket status back into ``In Review`` on Jira.

7) When a ticket has been backported to all requested releases, label your Jira ticket ``backport-done``.

.. _backports-fast-forward:

What If The Backport Can Be Fast Forwarded?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the fast-forward criteria is satisfied, maybe we should just instruct people to ask in a Slack channel for a pro to take over (#dm-build-support, perhaps?). I too like the fast-forward backports enough that I really do want to encourage them, but:

  • they are some pretty deep git-fu until you get used to them;
  • they sometimes require temporarily changing the branch protections, which not everyone can do (or not doing release branch protections, which has its own problems);
  • I think some combination of you, me, and maybe @mwittgen could clear any such requests them quickly.

===========================================

If the parent commit of your backport coincides with the release branch (or release candidate tag) you do not need to cherry pick and instead should fast forward.
Following on from step (3) above having created the release branch and pushed it.

4) At the merge commit on ``main`` of the code you are backporting, create a temporary ticket branch.

.. code-block:: bash

git checkout -b tickets/DM-XXXXX-v23

This branch exists solely to allow Jenkins to be tested as a convenience without having to find a commit ref for the merge to ``main``.

5) Run Jenkins as described above in step (5) using this temporary ticket branch.

6) When Jenkins passes you can now merge your ticket branch directly to the release branch.

.. code-block:: bash

git checkout v23.0.x
git merge --ff-only tickets/DM-XXXXX-v23
git push
git branch -d tickets/DM-XXXXX-v23

We ensure that the merge is a fast forward and this command will fail if it is not.
The ticket branch is not needed and can be deleted.
Loading