JDK 10 Rampdown Phase Two
The overall goal of this phase is to ensure that we fix just the bugs that must be fixed in order to ensure a successful release, and that we understand why we're not going to fix some bugs that perhaps ought to be fixed.
The specific goals are to:
-
Fix all P1 and P2 bugs that are new in JDK 10 and critical to the success of this release;
-
Decommit from fixing any P1 or P2 bugs that are not new in JDK 10 and are not critical to this release, but were previously targeted to this release; and
-
Explicitly defer any P1 or P2 bugs that are new in JDK 10 but are either not critical to this release or cannot, for good reason, be fixed in this release.
P3–P5 bugs whose fixes would affect product code must, at this point, be left to future releases.
P1 and P2 bugs
The current list of candidate Rampdown Phase Two (RDP 2) bugs can be found here: http://j.mp/jdk-rdp-2. If you're responsible for a bug on this list then you can take one of the following actions:
-
Develop a fix for the bug and then request approval to integrate it; or
-
If the bug is not new in JDK 10 (check the "Affects Version" field) then you can remove it from the list by clearing the "Fix Version" field, or by setting that field to
tbd_feature
if the fix would only be suitable for a feature release, or by setting that field totbd_update
if the fix would be suitable for any release; or -
If the bug is new in JDK 10 but is not critical or cannot be fixed in time then you can request that the bug be deferred explicitly from the release via the bug deferral process.
In any case, do not change the priority of a bug in order to remove it from the list. The priority of a bug should reflect the importance of fixing it independent of any particular release, as has been standard practice for the JDK for many years.
P3–P5 bugs
The RDP 2 candidate list only contains P1 and P2 bugs.
P3–P5 bugs are irrelevant to the overall status of the
release from this point forward, regardless of whether or not
they're targeted, so there's no need to take any specific action on
any P3–P5 bugs. You don't need to defer them, either
explicitly via the deferral process or even implicitly by adjusting
the "Fix Version" field, though you can set the value of that field
to tbd_feature
or tbd_update
if you think
that will be useful information later on.
P3–P5 bugs whose fixes only affect tests (or test problem
lists) or documentation may be fixed until the initial release
candidate build, on 2018/2/8. If you have a fix for such a bug then
you don't need to request approval in order to integrate it, but
please do make sure that the issue has a noreg-self
or noreg-doc
label, as appropriate.
Enhancements
The overall feature set is, at this point, frozen. No further JEPs will be targeted to this release.
Late, low-risk enhancements that add small bits of missing functionality or improve usability are permitted with approval, especially when justified by developer feedback, but the bar is extremely high. API or other specification changes made by a JSR Expert Group are critical by definition, and will be approved. You can request approval for an enhancement via the late-enhancement request process.