JDK 9 Release Candidate process proposal

[jesper.wilhelmsson at oracle.com]

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.

Thanks,
/Jesper

> On 18 Jun 2017, at 21:58, mark.reinhold at oracle.com wrote:
> 
> Per the JDK 9 schedule [1] 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 [2]; 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 [3]; 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 [4].
> 
> 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
> 
> 
> [1] http://openjdk.java.net/projects/jdk9/
> [2] http://openjdk.java.net/projects/jdk9/fix-request-process
> [3] 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.
> [4] http://openjdk.java.net/projects/jdk9/bug-deferral-process