JDK 9 Rampdown Phase 1: Process proposal

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