Rampdown Phase 2

Java 9 enters second bug fixing phase

Gabriela Motroc

Two finger posing image via Shutterstock

Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, announced in a message to the OpenJDK mailing list that the second phase of the rampdown process has begun.

It’s been seven months since Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, announced the first phase of the rampdown process in a message to the OpenJDK mailing list . Now it’s time for the second phase.

Reinhold proposed that the specific goals for this phase should be:

  • Fix all P1-P2 bugs that are new in JDK 9 and critical to the success of this release;
  • Decommit from fixing any P1-P2 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-P2 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.

The schedule seems to be working like clockwork now that the former schedule has been scrapped.

Java 9 schedule

Comments from JDK 9 Committers are due by 23:00 UTC on Thursday, 23 March.

Java 9 rampdown phase 2 overview

Reinhold explained that P3-P5 bugs whose fixes would affect product code must be left to future releases. P3-P5 bugs whose fixes only affect tests, documentation, or demos may be fixed until the first GA candidate build, on 2017/6/22.

The list of candidate Rampdown Phase 2 (RDP 2) bugs can be found here.

Those who are responsible for a bug on this list can take one of the following actions:

  • Fix the bug and then request approval to integrate the fix
  • If the bug is not new in JDK 9 (check the “Affects Version” field), it can be removed 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
  • 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.

However, one thing that should not be done is 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, Reinhold said.

SEE ALSO: Java 9: The draft Public Review Specification is out

The Chief Architect of the Java Platform Group proposed that they leverage the expertise of their Group and Area Leads by asking them to approve fixes prior to integration. This is how things should be done:

  • Before you spend too much time on a fix for a P1 or P2 bug, seek advice from a Group or Area Lead, on an appropriate mailing list, to make sure that fixing the bug in this release is actually a reasonable idea.
  • When you are nearly ready with a fix then update the JBS issue to add a comment whose first line is “Fix Request”. In that comment briefly describe why it’s important to fix this bug, explain the nature of the fix, estimate its risk, describe its test coverage, and indicate who has reviewed it. If you have a webrev for the fix then include a link to that in the comment; otherwise, attach the patch for the fix to the JBS issue. Add the label “jdk9-fix-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 to start and more frequently as we approach the GA date. One of them will either approve the request by adding the label “jdk9-fix-yes”, along with a comment recording their approval, reject the request by adding the label “jdk9-fix-no”, along with a comment describing the reason for this action or request more information by adding the label “jdk9-fix-nmi” (“nmi” = “needs more information”), along with a comment describing what information is requested.
  • If you’re asked to provide more information for a fix request then please do so in a new comment in the issue, and then remove the “jdk9-fix-nmi” label so that we see that it’s ready for re-review.
  • If your request is approved then proceed to complete the fix and integrate it. In any case, do not remove the original “jdk9-fix-request” label.

Reinhold announced that “the overall feature set is, at this point, frozen. Low-risk enhancements that add small bits of missing functionality or improve usability may be approved, especially when justified by developer feedback, but the bar is now extremely high. API or other specification changes made by a JSR Expert Group are critical by definition, and will be approved. Request approval for enhancements can be requested via the existing FC-extension process. As of RDP 2, only the JDK 9 Project Lead or a delegate, in the case of absence, may approve such requests.”

The goal of this process is to ensure that they fix just the bugs that must be fixed in order to ensure a successful release, and that they understand why they’re not going to fix some bugs that perhaps ought to be fixed.

Author
Gabriela Motroc
Gabriela Motroc is an online editor for JAXenter.com. Before working at S&S Media she studied International Communication Management at The Hague University of Applied Sciences.

Comments
comments powered by Disqus