JavaFX 23 is in Rampdown Phase Two (RDP2)

[Kevin Rushforth]

To: JavaFX Developers

As a reminder, JavaFX 23 is now in Rampdown Phase Two (RDP2). [1]

P1-P2 bug fixes, and test or doc fixes of any priority, can be fixed 
during RDP2. Explicit approval is needed for all bug fixes and 
enhancements (except for doc and test fixes) to go in to the jfx23 
branch [2]. The bar for approving bug fixes is appropriately high at 
this point. We do not anticipate approving any more enhancements.

Now that we are in RDP2, the goal is to stabilize what is there, fixing 
bugs that are new in JavaFX 23. We need to be extremely careful about 
including anything that introduces risk.

We will use the same rules for RDP2 that the JDK uses [3], with two 
modifications:

1. Approval is needed from one of the OpenJFX project leads (not the 
OpenJDK project lead)

2. Since we are not part of the JDK, we need to use labels that do not 
collide with the JDK 23 release. As an obvious choice, derived from the 
JBS fix version, we will use "jfx23-fix-request", "jfx23-fix-yes", 
"jfx23-fix-no" and "jfx23-fix-nmi", "jfx23-enhancement-request", 
"jfx23-enhancement-yes", "jfx23-enhancement-no" and 
"jfx23-enhancement-nmi" as corresponding labels.

REMINDER: In this release we will integrate almost all stabilization 
changes via backports from the master branch [4].

   * Almost all fixes intended for the jfx23 stabilization branch will 
also be applicable to the master branch. Integrate such a change into 
the master branch first. Then, after you have obtained any required 
approvals, backport it to the stabilization branch using the Skara 
`/backport` command or, if necessary, by manually opening a backport PR 
with the title `Backport $HASH`, where `$HASH` is the original commit 
hash.  (The JDK Developers’ Guide contains more information on working 
with backports [5].)

   * Some fixes will be specific to the stabilization branch and not 
applicable to the master branch. Integrate such a change directly into 
the stabilization branch.

IMPORTANT: Reviewers and Committers now have an extra responsibility to 
double-check the target branch of each PR that they review, integrate, 
or sponsor. By default a PR will be targeted to `master` which is the 
main development line (JavaFX 24 as of today). This is usually what we 
want. A backport PR should be targeted to `jfx23` if, and only if, it is 
intended for JavaFX 23 and meets the criteria for the current rampdown 
phase (we're in RDP2 as of today). Reviewers are advised to be extra 
cautious in approving potentially risky fixes targeted to `jfx23`. If 
there is a concern, then a reviewer can as part of the review indicate 
that the PR should be retargeted to `master` for 24 (or withdrawn if it 
is a backport of a fix already in `master`). Reviewers also need to be 
extra careful when reviewing PRs targeted to jfx23 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. This should be less of a 
problem for this release, since almost all PRs for jfx23 will be done as 
backport-style PRs, but it can still be a problem if the developer 
mistakenly merges master into their backport branch.

Let me know if there are any questions.

-- Kevin


[1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-May/046924.html

[2] https://github.com/openjdk/jfx/tree/jfx23

[3] http://openjdk.org/jeps/3

[4] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements

[5] https://openjdk.org/guide/#working-with-backports-in-jbs