Skip to content

DM-54042: Add some instructions for fast forward backporting #738

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
timj wants to merge 1 commit into
base: main
Choose a base branch
from
+49 −0
Open

DM-54042: Add some instructions for fast forward backporting #738

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
49 changes: 49 additions & 0 deletions work/backports.rst
View file
Open in desktop
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

@erykoff erykoff Feb 4, 2026

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

@TallJimbo TallJimbo Feb 4, 2026

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.

Copy link
Member Author

@timj timj Feb 4, 2026

Choose a reason for hiding this comment

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

I've added some example text in the section below (wasn't sure about adding even more to a note. I'll try to rephrase this sentence.

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,47 @@ 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

@TallJimbo TallJimbo Feb 4, 2026

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.

Copy link
Member Author

@timj timj Feb 4, 2026

Choose a reason for hiding this comment

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

Isn't it simpler to fast forward than follow the other instructions? In essence it's git merge commit-from-main. I think I've decided that the branch protections on v*.0.x branches that require pull requests are more painful than useful and I've been turning them off permanently.

Copy link
Member

@TallJimbo TallJimbo Feb 4, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Fast forwards are simpler but less familiar to devs, I think. Anyhow, I think it's true that the trickier business is working out whether a fast-forward is viable and we do have to rely on everybody to do that (unless we institute reviews or something for backports). Maybe it's something we can start pointing out when doing backport approvals (though that ship has almost entirely sailed for v30).

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

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.
For example, in this git example from ``daf_butler`` we would like to backport the fix for DM-52738 to v30:

.. code-block:: bash

* 25fb39d38 - (tag: w.2026.04) Merge pull request #1322 from lsst/tickets/DM-52738 (13 days ago)
|\
| * 10f3bb0b0 - Fix bug in expandDataId with kwargs. (2 weeks ago)
| * c5e14e5e7 - Add convenience iteration method to DatasetRefURIs. (2 weeks ago)
| * f7b71d1fc - Expand data IDs when making predicted paths. (2 weeks ago)
|/
* f58e329d0 - (origin/v30.0.x, v30.0.x, tag: v30.0.0.rc3, tag: 30.0.0) Merge pull request #1321 from lsst/tickets/DM-53844 (2 weeks ago)

We can see that there are no other commits between what we would like to backport and the v30.0.x release branch, making this an ideal candidate for a fast forward merge to the branch.

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