[jfx24] RFR: Merge ecec2645a99a9c1343ddf08c4009df578d5b2165 [v2]
Kevin Rushforth
kcr at openjdk.org
Wed Jan 22 19:01:58 UTC 2025
On Tue, 21 Jan 2025 15:53:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>> Clean merge of January CPU content into ~~jfx:master~~ `jfx:jfx24`.
>>
>> Reviewer: @johanvos
>
> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>
> - Merge branch 'jfx25-cpu-2501' into merge-jfx25-cpu-2501
> - Merge
> - Merge
> - Merge
> - Merge
> - Merge
> - Merge
> - Merge
> - Merge
> - 8335714: Enhance playing MP3s
>
> Reviewed-by: arapte, kcr, mschoene, rhalade
> - ... and 1 more: https://git.openjdk.org/jfx/compare/6a70eab6...f6262cd9
To follow-up on this, for future reference, I made a mistake in this PR, which I didn't catch until earlier this morning while forking the (soon-to-be-open) `jfx24u` repo from the `jfx:jfx24 branch`
> To add a little more explanation: as happens every January and July, any CPU content must be merged into both to master and to the then-current stabilization branch (jfx24 for this January 2025 CPU release). My only mistake is that I targeted both PRs to master when one of them should have been to jfx24.
So far, this is accurate, and would have been completely fixable without further problems, but...
> Since the source branches were 100% identical
Stop right there, Kevin! While it is true that I created the PR branches from a pair of 100% identical internal branches (the exact same HEAD hash, which is reflected in the PR title), I merged in the intended target branches before creating the PR, meaning I merged `master` into `merge-jfx25-cpu-2501`; consequently, `merge-jfx25-cpu-2501`, which is the source branch for this PR, has one additional commit -- the version bump from jfx24 to jfx25 -- relative the `merge-jfx24-cpu-2501` branch, which was originally intended for `jfx24`.
NOTE: The result of the extra commit (the unintended version bump) is visible in the diffs, which I didn't look at carefully enough before deciding to take the following shortcut:
> the mistake was easiest to fix by retargeting this one to jfx24, which I did. I'll integrate this PR to jfx24 after everything else related to the CPU is finished.
No. The mistake would have been easiest to fix by _not_ taking this shortcut. Better would have been to close this PR and create a new one from the right branch.
I remedied the problem earlier today with PR #1682 to revert the version bump in the `jfx24` branch. All good now, but I'll repeat my own advice from my [JavaFX 24 RDP1 message](https://mail.openjdk.org/pipermail/openjfx-dev/2025-January/051749.html), at least for my own benefit:
"...be extra careful when reviewing PRs targeted to jfx24 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed."
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1680#issuecomment-2608034310
More information about the openjfx-dev
mailing list