To: JavaFX Developers
As a reminder, JavaFX 22 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 jfx22
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 22. 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 22 release. As an obvious choice, derived from the
JBS fix version, we will use "jfx22-fix-request", "jfx22-fix-yes",
"jfx22-fix-no" and "jfx22-fix-nmi", "jfx22-enhancement-request",
"jfx22-enhancement-yes", "jfx22-enhancement-no" and
"jfx22-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 jfx22 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 23 as of today). This is usually what we
want. A backport PR should be targeted to `jfx22` if, and only if, it is
intended for JavaFX 22 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 `jfx22`. If
there is a concern, then a reviewer can as part of the review indicate
that the PR should be retargeted to `master` for 23 (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 jfx22 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 jfx22 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/2023-September/042703.html
[2] https://github.com/openjdk/jfx/tree/jfx22
[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
