JDK 9 Rampdown Phase 1: Process proposal
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Wed Aug 31 14:57:30 UTC 2016
Per the JDK 9 schedule , the first phase of the Rampdown process
starts tomorrow. The overall goal of this process is to ensure that
we're fixing the bugs that need to be fixed, and that we understand why
we're not fixing some bugs that ought to be fixed. For this release I
propose that our specific goals for this phase should be:
- Fix all P1-P3 bugs that are new in JDK 9,
- Fix additional P1-P3 bugs targeted to JDK 9 as time permits, and
- Explicitly defer any P1-P2 bugs that are new in JDK 9 but will not,
for good reason, be fixed in JDK 9.
P4-P5 bugs should, in general, be left to future releases unless they
only affect documentation, demos, or tests, in which case they should be
identified as such with the "noreg-doc", "noreg-demo", and "noreg-self"
The current list of candidate Rampdown Phase 1 (RDP1) bugs can be found
here: http://j.mp/jdk9-rdp1 . If you're responsible for a bug on this
list then you can take one of the following actions:
- Fix the bug (preferred), or
- If the bug is not new in JDK 9 (check the "Affects Version" field)
then you can un-target it from JDK 9 by clearing the "Fix Version"
field or setting that field to some future release, or
- If the bug is new in JDK 9 and is P1 or P2 but it cannot be fixed in
time then you can request that the bug be deferred from the release.
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.
To document the reason for deferring a P1 or P2 bug I propose the
- Request a deferral by updating the JBS issue to add a comment whose
first line is "Deferral Request". In that comment briefly describe
the reason for the deferral (e.g., insufficient time, complexity or
risk of fix, etc.). Add the label "jdk9-defer-request" to the issue.
- The Area Leads, relevant Group Leads, and the JDK 9 Project Lead will
review such requests on a regular basis, at least weekly if not more
often. One of them will take one of the following actions:
- Approve the request by adding the label "jdk9-defer-yes".
- Reject the request by adding the label "jdk9-defer-no", along
with a comment describing the reason for this action.
- Request more information by adding the label "jdk9-defer-nmi"
("nmi" = "needs more information"), along with a comment
describing what information is requested.
- If you're asked to provide more information for a deferral request
then please do so in a new comment in the issue, and then remove the
"jdk9-defer-nmi" label so that we see that it's ready for re-review.
- If your request is approved then clear the issue's "Fix Version"
field or set it to some future release.
- In any case, do not remove the original "jdk9-defer-request" label.
Deferrals will not be granted for TCK issues identified by the label
"tck-red-9" . Deferrals are also unlikely for bugs that prevent
For the record, the Area Leads are Mikael Vidstedt (VM), Brian Goetz
(Language and Libraries), and Kevin Rushforth (Client Libraries).
The relevant Group Leads are as follows, per the Census :
Sergey Bylokhov - AWT
Tim Bell - Build
Jonathan Gibbons - Compiler
Alan Bateman - Core Libraries
Vladimir Kozlov - HotSpot
Masayoshi Okutsu - Internationalization
Michael McMahon - Networking
Dalibor Topic - Porters
Sean Mullan - Security
Staffan Larsen - Serviceability
Alexander Scherbatiy - Swing
Phil Race - 2D Graphics & Sound
JDK 9 Committers are invited to comment on this process proposal. If
no serious objections are raised in one week's time, by 15:00 UTC next
Wednesday, 7 September 2016, then this is the process that we'll use.
In anticipation that we'll use this process, more or less, owners of
bugs on the RDP1 candidate list are encouraged to proceed as outlined
above. This will allow us to move quickly once the process is in
More information about the jdk9-dev