JDK 9 Rampdown Phase 1: Process proposal

[mark.reinhold at oracle.com]

Per the JDK 9 schedule [1], 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"
labels, respectively.

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
following process:

  - 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" [2].  Deferrals are also unlikely for bugs that prevent
release testing.

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 [3]:

  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
place.

- Mark


[1] http://openjdk.java.net/projects/jdk9/
[2] https://bugs.openjdk.java.net/issues/?filter=18893
[3] http://openjdk.java.net/census