JDK 9 Rampdown Phase 1: Process proposal
jesper.wilhelmsson at oracle.com
Wed Aug 31 16:18:53 UTC 2016
Please note that removing the fix version is not an option for bugs on the
Hotspot component. Hotspot bugs should always have a fix version set and
currently we are deferring by setting the fix version to 10.
Den 31/8/16 kl. 16:57, skrev mark.reinhold at oracle.com:
> Per the JDK 9 schedule , 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" . 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 :
> 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
> - Mark
>  http://openjdk.java.net/projects/jdk9/
>  https://bugs.openjdk.java.net/issues/?filter=18893
>  http://openjdk.java.net/census
More information about the jdk9-dev