Yicong-Huang opened a new pull request, #58288: URL: https://github.com/apache/spark/pull/58288
### What changes were proposed in this pull request? This PR adds an interactive prompt to `dev/merge_spark_pr.py` that lets the committer update the JIRA Affects Version/s (`issue.fields.versions`) during `resolve_jira_issue`, mirroring the existing Fix Version prompt. Previously Affects Version/s were display-only in `print_jira_issue_summary` while Fix Version/s had a full prompt/validate/retry loop. The prompt is only offered when the affected floor is inconsistent with the fix, i.e. when the earliest fix version precedes the earliest recorded Affects Version (`fix_precedes_affects`), so normal merges are not interrupted. It runs in two places: - On a **fresh resolve**, when the recorded Affects Version/s sit above the fix version just chosen (e.g. fixed in `4.4.0` but recorded as affecting only `5.0.0`). - On a **backport resolve** (an already-resolved ticket gaining an earlier fix line), when the new fix line is below the affected floor (e.g. affects `4.4.0`, backport adds fix `4.3.1`) -- the backport implies that earlier line is affected too, so the Affects Version/s should extend down. The suggested default is derived from the fix version(s) (`suggest_affects_versions`): it keeps every recorded affected version not later than the highest fix version and adds the fix versions, then the committer can accept it (blank) or type their own, validated against all unarchived project versions (an affected version may name a released one) with a retry loop. The write goes through the existing `jira_ops` wrapper, so `--dry-run` only logs the intended change. Fix Version, assignee, and component logic are untouched. New pure helpers `parse_affects_versions_input`, `fix_precedes_affects`, and `suggest_affects_versions` carry doctests. ### Why are the changes needed? The merge script already reconciles assignee, components, and Fix Version/s with the committer, but the Affects Version/s were read-only. Reporters often record an affected version that is inconsistent with where the fix actually lands -- too high on a fresh resolve, or missing an earlier line that a later backport reveals as affected -- and there was no in-flow way to correct it. Deriving a suggestion from the fix version(s) makes the common correction a single keystroke while leaving normal, already-consistent tickets untouched. ### Does this PR introduce _any_ user-facing change? No. This only affects the committer-facing merge tooling. ### How was this patch tested? Added doctests for the three new pure helpers, run via the script's existing `doctest.testmod()` entry point (`python -m doctest dev/merge_spark_pr.py`; all pass). Also exercised the interactive flow locally with a stubbed JIRA issue and the `DryRunJira` ops across fresh-resolve and backport scenarios (silent when affects already covers the fix, prompt with a fix-derived suggestion when it does not, blank accepts the suggestion, invalid input retries). ### Was this patch authored or co-authored using generative AI tooling? No. -- 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]
