OpenJFX 14 is now in Rampdown Phase One (RDP1) [1]. We have forked a new
jfx14 branch [2] for stabilizing the OpenJFX 14 release.
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 OpenJFX 15. Most fixes will be integrated to
master for 15.
- The jfx14 branch of the jfx repo is now open for integrating fixes for
OpenJFX 14 that meet the RDP1 criteria as outlined below.
- Reviewers and Committers now have an additional responsibility to
verify the target branch of each pull request.
- I will periodically sync jfx14 --> master, meaning that developers
should integrate fixes to one or the other, not both
DETAILS:
P1-P3 bug fixes, and test or doc fixes of any priority are good
candidates for integrating to jfx14 during RDP1. The only hard
restriction is that enhancements need explicit approval, over and above
the review of the PR, to go into jfx14. The bar for such approval is
high: we do not anticipate approving any more enhancements. We also need
to be careful to avoid potentially risky fixes during this time. Note
that these restrictions apply to the jfx14 branch. The master branch is
open for all openjfx15 fixes, including enhancements.
With the switch to git for our official repo, we are now using a single
openjdk/jfx GitHub repo with stabilization branches [3] rather than
creating separate stabilization repos, which we used to do with
Mercurial. The jfx14 branch of the openjdk/jfx git repo is conceptually
the same as the 13-dev/rt HG repo that was used for stabilizing
openjfx13, but the mechanics are slightly different, so please be aware,
especially if you are a Reviewer or Committer in the Project. This
change should make it much easier for developers (no need to clone from
multiple repos), and will allow all pull requests to all be in the same
place, but care needs to be taken for any PR that is targeted to jfx14
to ensure that it doesn't contain any commits from master after the
jfx14 fork date. What that means is that if you intend a PR to be for
jfx14, 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 (OpenJFX 15 as of today). A PR should be targeted
to `jfx14` if, and only if, it is intended for OpenJFX 14 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 `jfx14`. If there is a concern, then a reviewer
can as part of the review indicate that the PR should be retargeted to
`master` for 15. Reviewers also need to be extra careful when reviewing
PRs targeted to jfx14 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.
We will use the same rules for RDP1 that the JDK uses [4], 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 14 release. As an obvious choice, derived from the
JBS fix version, we will use "openjfx14-enhancement-request",
"openjfx14-enhancement-yes", "openjfx14-enhancement-no" and
"openjfx14-enhancement-nmi" as corresponding labels.
3. No explicit approval (no JBS labels) is needed to integrate P4 bugs
to jfx14 branch during RDP1, as long as those bugs have otherwise met
the usual code review criteria. Having said that, most P4 bugs should
now go into master for openjfx15, since we do not want to risk anything
that would destabilize the openjfx14 release without a compelling
reason. Also, we have less than 4 weeks until RDP2 of openjfx14 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 openjfx14 during this
time.
Let me know if there are any questions.
-- Kevin
[1]
https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-December/024331.html
[2] https://github.com/openjdk/jfx/tree/jfx14
[3] https://github.com/openjdk/jfx/branches/all
[4] http://openjdk.java.net/jeps/3
