OpenJDK Governing Board Minutes: 2017/8/24

The OpenJDK Governing Board met via conference call on Thursday, 24 August 2017 at 16:00 UTC with the following agenda:

  1. Accelerating the JDK release cadence
  2. Infrastructure Update: CSR and Submission Forest
  3. Any other business

Five Board members were present: Georges Saab, Andrew Haley (about 15 minutes late), Doug Lea, John Duimovich, and Mark Reinhold.

The intent of these minutes is to capture the conversational flow of the Board's discussion and also to record decisions. If you are interested only in the latter then search for the word "AGREED" throughout the text.

0. Vulnerability Group

Georges started the meeting by calling attention to the Vulnerability Group proposal that Mark sent yesterday. Doug thought that people seemed happy and were asking good questions.

1. Accelerating the JDK release cadence

Proceeding to the release cadence item, Mark began by saying that changes to the release cadence had been previously discussed in various public forums. To begin the discussion in the OpenJDK Community, Mark was preparing a blog entry (now published) for publication in a week or two. He provided the following preview:

Java SE and the JDK have done reasonably well on a feature-driven release model for the past 20 years. For Java to remain competitive, however, it needs to move at a faster pace. Some may recall that a two-year, time-based model was proposed several years ago. It was never adopted, however, because completing key features and addressing security issues was judged to be more important than maintaining the two-year cadence. Under the new proposal a major release will ship every six months and can include any type of feature (language, JVM, and API changes). Quarterly updates will continue. Every three years the update release line will be extended to a long-term support release.

Andrew said that he could understand selected features and performance updates every six months, but he questioned whether the Java SE Specification could be updated at that rate. Mark replied that updating the Platform Specification was a significant challenge. However, he noted that Georges and Brian Goetz had spent eight months (so far) with a subset of the Java Community Process (JCP) Executive Committee identifying ways to streamline the JCP Process. Andrew commented that updating the JCP Process to support a faster release cadence was beyond the limits of what he thought was possible. Mark answered that the discussed updates to the JCP Process would allow a JSR to complete in a minimum of 3.5 months, making a six month release cadence possible. He noted that the JCP Process was created at a time when development was very proprietary. The greater transparency of Java SE development in modern times enables many process optimizations.

Georges observed that releases on a six month cadence would have significantly less content than those published every two years. Also, rather than working for months or years on a fully-formed draft Specification, there would be continuous publication of the Specification on a regular (weekly or bi-weekly) basis. Mark added that significant features such as language and VM Specification changes would be published before the JCP Process for the release started. When Doug mentioned that a release could be skipped, Mark agreed that part of the beauty of a six month release cadence was that skipping a release would be painful but not tragic.

In the context of the OpenJDK Community, Mark described a few additional changes that were forthcoming. First, long-running OpenJDK Projects called "JDK" for major releases and "JDK Updates" for update releases would be introduced. The existence of these Projects would reduce release start-up costs. Next, "pure" JDK builds (without Oracle features) would be available. Finally, Java Flight Recorder (JFR) and other closed or commercial Oracle features will be open-sourced over the next 1 - 1.5 years.

Andrew steered the conversation to the challenge of dropping features late in a release. Eclipse could drop a feature 24 hours before a release since features tended to be isolated. The same was not true for HotSpot. Mark and Georges both observed that a feature should not go into a release until the feature was believed to be complete. Further if the feature conflicts with something, then it should not go in. John suggested using feature flags to allow a feature to be added without being enabled. Mark replied that the technique was regularly used but was not always practical. Georges said that Incubator Modules was another mechanism that could be used to achieve a similar goal.

John asked whether it would be possible to have a repository of patches for minor problems that had been solved. The expectation was that the repository would eventually be drained. Mark replied that if somebody had patches for problems they'd like addressed, they could simply propose and fix them. Mark was skeptical that the described repository would get very much attention. Doug agreed saying that he did not have the impression that the described class of changes were interesting.

Andrew asked how the release repositories would be managed. Mark said that the initial thought was that the JDK Project main line would always be open. Three months before a release, a stabilization branch would be created which would become the major release. The standard milestones for stabilization would be applied to the branch.

2. Infrastructure Update: CSR and Submission Forest

Mark reminded the Board about the JPRT submission forests which were announced at FOSDEM. These forests allowed Committers to use JPRT to build and test their changes to HotSpot for JDK 9. Andrew Haley and Volker Simonis both provided feedback at that time. The intent was to make the forests more widely available. Unfortunately, the JDK 10 equivalent submission forests did not exist because JPRT has been completely replaced. The submission system needed to be re-targeted to JDK 10.

The ultimate goal is to work with others to provide a build and test system that does not run within a corporate firewall. Doug thought the ultimate goal was great and suggested speaking to Google as a further enhancement. Georges remarked that the technology that Mark referenced was three generations old. The technology in use is one generation old and the next technology was under investigation.

3. Any other business

No other business was identified.