OpenJFX 14 is in Rampdown Phase One (RDP1)

[Kevin Rushforth]

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