JDK 9 Rampdown Phase 1: Process proposal

[Stephen Colebourne]

Given that the major feature of JDK 9 (modules/jigsaw) still has major
outstanding unresolved issues [1] and the schedule still suggests
feature complete should have been over three months ago (26th May
2016) [2], the schedule on which this email is based is clearly deeply
flawed.

I am also very uncomfortable with the notion that modules - a complex,
difficult and still highly debated feature - is still far from
complete, and yet about to be rushed to meet an artificial timeline.

Stephen

[1] http://openjdk.java.net/projects/jigsaw/spec/issues/
[2] http://openjdk.java.net/projects/jdk9/


On 31 August 2016 at 15:57,  <mark.reinhold at oracle.com> wrote:
> 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