zhengruifeng commented on PR #58165:
URL: https://github.com/apache/spark/pull/58165#issuecomment-5363727688
Thanks, this is a good point. I think there are three different backport
flows here:
1. Happy path: we merge a PR to master and backport it in the same
`merge_spark_pr.py` invocation. In this case the script sees all merged
refs
together and can set all Fix Versions correctly.
2. The master PR was merged first, and later we decide to backport the same
merged PR to more branches using `merge_spark_pr.py` backport mode. In
this
case the JIRA is already resolved, but the later backport merge still
needs
to add the newly inferred Fix Versions. This is the case fixed by
84a309d91f702b2434e8525ff36e77d88f6a61cc / SPARK-58754.
3. The PR cannot be backported cleanly while merging to master because of
code
conflicts, so we merge the master PR first and then open a separate PR
targeting the release branch with the conflict resolution. This is
becoming
more common as branches diverge; I hit this twice this week. In that case
the branch PR is a normal open PR, not the "already merged PR backport
mode"
from case 2, but the linked JIRA is already resolved from the master merge
and we still need to add the release-branch Fix Version while merging the
branch PR. PR #58147 -> #58184 is one example. Another is #58129 ->
#58150:
the master-side PR was merged first, then a separate release-branch PR was
needed because the backport could not be completed directly from the
original
merge flow.
So I agree we should not blindly update every resolved/closed JIRA. But
checking
for empty Fix Versions is too narrow, because cases 2 and 3 both need to add
additional Fix Versions to an already resolved issue that may already have
the
master Fix Version.
One related issue is that branch-4.x-only merges currently do not infer the
4.x
Fix Version unless master is also in `merge_branches`, so I may need to
adjust
the inference for separate release-branch PRs too.
--
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]
