viirya opened a new pull request, #56058:
URL: https://github.com/apache/spark/pull/56058
### What changes were proposed in this pull request?
When a committer manually types `branch-M.N` at the cherry-pick prompt while
`branch-M.x` exists and has not yet received the commit, the script now
surfaces the Upstream-First policy and offers to pick into both branches in one
step (the policy-compliant default). The committer can still pick only
`branch-M.N` if the commit is genuinely a `branch-M.N`-only maintenance bugfix,
or abort.
Implementation notes:
- Split `cherry_pick` into `_do_cherry_pick` (fetch + cherry-pick + push)
and `cherry_pick` (prompt + policy check). The policy wrapper returns a list of
refs so the main loop can advance its remaining-branches list correctly when
one prompt consumes two branches.
- Replace the `branch_iter` iterator with a mutable `remaining_branches`
list in the main cherry-pick loop, so picks consumed by the two-branch path are
accounted for in the next prompt's default.
- Add an `already_picked` parameter to `cherry_pick` so the policy check
skips its prompt when `branch-M.x` is in the set of refs already touched this
session (e.g. when the PR was merged into `branch-M.x` and the loop is now
picking into `branch-M.N`).
### Why are the changes needed?
The Upstream-First backporting policy (documented in the header comment of
\`dev/merge_spark_pr.py\`) requires non-bugfix commits to flow through
`branch-M.x` before reaching `branch-M.N`. The merge script already orders
`branch-M.x` ahead of `branch-M.N` as the cherry-pick default. However, when a
committer types `branch-M.N` at the prompt, the script silently proceeds and
`branch-M.x` is never revisited.
This has led to commits landing on `branch-4.2` but missing `branch-4.x`.
Six such commits observed on the current branches (as of 2026-05-22):
- SPARK-56700 (#55651)
- SPARK-56676 (#55623)
- SPARK-56838 (#55836)
- SPARK-56650 (#55589)
- SPARK-56856 (#55969)
- SPARK-56977 (#56023)
All six landed on master and `branch-4.2` but were not cherry-picked to
`branch-4.x`, requiring follow-up backports.
### Does this PR introduce _any_ user-facing change?
Yes for committers using `dev/merge_spark_pr.py`. When the typed cherry-pick
target is `branch-M.N` and `branch-M.x` exists and is not yet picked, an
additional prompt asks whether to pick into both. Accepting the default
("both") preserves prior behavior plus an extra cherry-pick to `branch-M.x`.
No change when the committer accepts the default `branch-M.x` target, or
when picking into `branch-M.x` first and `branch-M.N` second (the typical
policy-compliant flow).
### How was this patch tested?
- `python3 -c "import py_compile;
py_compile.compile('dev/merge_spark_pr.py', doraise=True)"` passes.
- `python3 -m doctest dev/merge_spark_pr.py` passes (34/34).
Behavior was traced by reading the script (no actual merge run, since that
requires committer privileges + a live PR).
### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.7)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
