JDK 9 Rampdown Phase 2: Process proposal
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Thu Mar 16 22:51:43 UTC 2017
Per the JDK 9 schedule , we are now entering the second phase of the
rampdown process. The overall goal of this process 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. I propose that our specific goals for
this phase should be:
- Fix all P1-P2 bugs that are new in JDK 9 and critical to the success
of this release;
- Decommit from fixing any P1-P2 bugs that are not new in JDK 9 and
are not critical to this release, but were previously targeted to
this release; and
- Explicitly defer any P1-P2 bugs that are new in JDK 9 but are either
not critical to this release or cannot, for good reason, be fixed in
P3-P5 bugs whose fixes would affect product code must be left to future
releases. P3-P5 bugs whose fixes only affect tests, documentation, or
demos may be fixed until the first GA candidate build, on 2017/6/22.
Please make sure that such bugs have a "noreg-self", "noreg-doc", or
"noreg-demo" label, as appropriate.
The current list of candidate Rampdown Phase 2 (RDP 2) bugs can be found
here: http://j.mp/jdk9-rdp2 . If you're responsible for a bug on this
list then you can take one of the following actions:
- Fix the bug and then request approval to integrate the fix (see
- If the bug is not new in JDK 9 (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_major" if the fix would only
be suitable for a major release, or by setting that field to
"tbd_minor" if the fix would be suitable for any release ; or
- If the bug is new in JDK 9 but is not critical or cannot be fixed in
time then you can request that the bug be deferred explicitly from
the release, using the deferral process that we adopted earlier for
RDP 1 .
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 ensure that we manage risk wisely I propose that we leverage the
expertise of our Group and Area Leads by asking them to approve fixes
prior to integration. Let's use a process similar to those that we've
- Before you spend too much time on a fix for a P1 or P2 bug, seek
advice from a Group or Area Lead, on an appropriate mailing list,
to make sure that fixing the bug in this release is actually a
- When you are nearly ready with a fix then update the JBS issue to add
a comment whose first line is "Fix Request". In that comment briefly
describe why it's important to fix this bug, explain the nature of
the fix, estimate its risk, describe its test coverage, and indicate
who has reviewed it. If you have a webrev for the fix then include a
link to that in the comment; otherwise, attach the patch for the fix
to the JBS issue. Add the label "jdk9-fix-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 to start and
more frequently as we approach the GA date. One of them will take
one of the following actions:
- Approve the request by adding the label "jdk9-fix-yes", along
with a comment recording their approval.
- Reject the request by adding the label "jdk9-fix-no", along
with a comment describing the reason for this action.
- Request more information by adding the label "jdk9-fix-nmi"
("nmi" = "needs more information"), along with a comment
describing what information is requested.
- If you're asked to provide more information for a fix request then
please do so in a new comment in the issue, and then remove the
"jdk9-fix-nmi" label so that we see that it's ready for re-review.
- If your request is approved then proceed to complete the fix and
- In any case, do not remove the original "jdk9-fix-request" label.
The overall feature set is, at this point, frozen. Low-risk enhancements
that add small bits of missing functionality or improve usability may be
approved, especially when justified by developer feedback, but the bar
is now 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 enhancements via the existing FC-extension process
. As of RDP 2, only the JDK 9 Project Lead or a delegate, in the case
of absence, may approve such requests.
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
Naoto Sato - 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 23:00 UTC next
Thursday, 23 March, 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 RDP 2 candidate list are encouraged to proceed as outlined above.
This will allow us to move quickly once the process is in place.
 You can also set the "Fix Version" field to a specific future
release, but bear in mind that by doing so you create the need
to review the bug yet again during that future release.
More information about the jdk9-dev