JavaFX 21 is in Rampdown Phase One (RDP1)

[Kevin Rushforth]

JavaFX 21 is now in Rampdown Phase One (RDP1) [1]. We have forked a new 
jfx21 branch [2] for stabilizing the JavaFX 21 release.

PLEASE READ CAREFULLY as the procedure for getting fixes into the 
stabilization branch has changed.

Here is the short summary of what this means:

- The master branch of the jfx repo is available for integrating bug 
fixes or enhancements for jfx22. Almost all fixes will be integrated to 
master for 22, even those intended to be fixed in 21.

- The jfx21 branch of the jfx repo is now open for integrating fixes for 
jfx21 that meet the RDP1 criteria as outlined below. In contrast to past 
practice, in this release we will integrate almost all stabilization 
changes via backports from the master branch [3].

   * Almost all fixes intended for the jfx21 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 [4].)

   * 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.

- Reviewers and Committers now have an additional responsibility to 
verify the target branch of each pull request.


DETAILS:

P1-P3 bug fixes, and test or doc fixes of any priority are good 
candidates for integrating to jfx21 during RDP1. The only hard 
restriction is that enhancements need explicit approval, over and above 
the review of the PR, to go into jfx21. The bar for such approval is 
appropriately high. We also need to be careful to avoid potentially 
risky fixes during this time. Note that these restrictions apply to the 
jfx21 branch. The master branch is open for all jfx22 fixes, including 
enhancements.

As a reminder, we use a single openjdk/jfx GitHub repo with 
stabilization branches [5] rather than a separate stabilization repo. 
The jfx21 branch is used to stabilize the upcoming jfx21 release. Please 
be aware of this, especially if you are a Reviewer or Committer in the 
Project. This allows all pull requests to be in the same place, but care 
needs to be taken for any PR that is targeted to jfx21 to ensure that it 
doesn't contain any commits from master after the jfx21 fork date. What 
that means is that if you intend a PR to be for jfx21, don't merge 
master into your local source 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 22 as of today). This is usually what we 
want. A backport PR should be targeted to `jfx21` if, and only if, it is 
intended for JavaFX 21 and meets the criteria for the current rampdown 
phase (we're in RDP1 as of today). Reviewers are advised to be extra 
cautious in approving potentially risky fixes targeted to `jfx21`. If 
there is a concern, then a reviewer can as part of the review indicate 
that the PR should be retargeted to `master` for 22. Reviewers also need 
to be extra careful when reviewing PRs targeted to jfx21 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 jfx21 will be done as 
backport-style PRs, but it can still be a problem if the developer 
mistakenly merges master into their backport branch.

We will use the same rules for RDP1 that the JDK uses [6], with the same 
three modifications we did for the previous release:

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 21 release. As an obvious choice, derived from the 
JBS fix version, we will use "jfx21-enhancement-request", 
"jfx21-enhancement-yes", "jfx21-enhancement-no" and 
"jfx21-enhancement-nmi" as corresponding labels.

3. No explicit approval (no JBS label) is needed to integrate P4 bugs to 
the jfx21 branch during RDP1, as long as those bugs have otherwise met 
the usual code review criteria. Having said that, most P4 bugs should 
only go into master for jfx22, since we do not want to risk anything 
that would destabilize the jfx21 release without a compelling reason. 
Also, we have only 3 weeks until RDP2 of jfx21 and we would be better 
served fixing higher priority bugs. Note that doc bugs and test bugs of 
any priority are fine to fix for jfx21 during this time.

Let me know if there are any questions.

-- Kevin

[1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-April/039630.html

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

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

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

[5] https://github.com/openjdk/jfx/branches/all

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