JDK 9 Rampdown Phase 2: Process proposal

[mark.reinhold at oracle.com]

Per the JDK 9 schedule [1], 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
    this release.

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
    below); or

  - 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 [2]; 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 [3].

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
already established:

  - 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
    reasonable idea.

  - 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
    integrate it.

  - 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
[4].  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 [5]:

  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.

- Mark


[1] http://openjdk.java.net/projects/jdk9/
[2] 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.
[3] http://openjdk.java.net/projects/jdk9/bug-deferral-process
[4] http://openjdk.java.net/projects/jdk9/fc-extension-process
[5] http://openjdk.java.net/census