JDK 9 Release Candidate process proposal
jesper.wilhelmsson at oracle.com
jesper.wilhelmsson at oracle.com
Mon Jun 19 14:33:09 UTC 2017
Please note that for any bugs in the hotspot and core-svc component stricter rules around fix versions are applied.
In these areas all bugs needs to have a valid JDK version as fix version (a value like 10, 11, 12, etc). Leaving the fix version blank is not an option and the buckets tbd_minor and tbd_major are not used. Buckets like 8-pool and 9-pool are only used for backports.
> On 18 Jun 2017, at 21:58, mark.reinhold at oracle.com wrote:
> Per the JDK 9 schedule  we are now approaching the Initial Release
> Candidate milestone. After this week's build, which will be promoted
> on Thursday (2017/6/22), we should fix only those bugs that are truly
> showstoppers to the success of the release. I propose that we further
> tighten the goals previously adopted for RDP 2:
> - Fix all P1 bugs that are new in JDK 9 and critical to the success
> of this release;
> - Decommit from fixing any P1 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 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.
> All P2-P5 bugs must be left to future releases, regardless of whether
> they are in product code, tests, or documentation. There is no need
> to defer unfixed P2-P5 bugs explicitly.
> The current list of RC bugs can be found here: http://j.mp/jdk9-rc .
> If you're responsible for a bug on this list then, just as in RDP 2,
> you can take one of the following actions:
> - Fix the bug and then request approval to integrate the fix, using
> the existing fix-request process ; 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 ; 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 .
> 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.
> The overall feature set has been frozen for some time now. No further
> enhancements, no matter how small and low-risk, will be approved after
> the Initial Release Candidate build.
> JDK 9 Committers are invited to comment on this process proposal. If
> no serious objections are raised in one week's time, by 08:00 UTC next
> Monday, 26 June, then this is the process that we'll use.
> - Mark
>  http://openjdk.java.net/projects/jdk9/
>  http://openjdk.java.net/projects/jdk9/fix-request-process
>  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.
>  http://openjdk.java.net/projects/jdk9/bug-deferral-process
More information about the jdk9-dev