OpenJDK Governing Board Minutes: 2021/04/22

The OpenJDK Governing Board met via video conference call on Thursday, 22 April 2020 at 16:00 UTC with the following agenda:

  1. Author role delays
  2. JEP Process issues
  3. Vulnerability Group infrastructure
  4. GB minutes delays
  5. Any other business

Five Board members were present: Andrew Haley, Samir Kamerkar (until about 16:30 UTC), Mark Reinhold, Georges Saab, and Christian Thalinger (starting at about 16:25 UTC).

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. Overview

As the meeting began, there was a brief discussion about attendance. Samir had a conflict which required him to leave early. When and if Chris arrived, he would be brought up to speed regarding the topics he had missed. With at least four Board members present at any time, the meeting was quorate.

Georges thanked Andrew for the agenda items and asked him to provide an overview. Andrew said that all of these topics were brought to his attention during the recent Governing Board election, so he was channeling concerns collected from others. He recommended that the items be handled slightly out order, so as to address easier topics first.

4. GB minutes delays

Andrew observed that most of the minutes for last year's meetings were published shortly after the beginning of the election. He recommended that minutes be published within two weeks after each meeting. Georges noted that this was not the first time that the publication delay had been a problem. He confirmed that all outstanding meeting minutes had been published. Georges said that excessive delays make it more difficult to verify whether the minutes are an accurate reflection of the meetings, and agreed that two weeks was a reasonable deadline. He planned to check in a week to ensure that the minutes of this meeting would be ready for review by Governing Board members in time for publication within two weeks.

1. Author role delays

Andrew relayed reports that it sometimes takes a couple of weeks for requests for the Author role to be processed. He speculated that it was likely that people are most concerned about Author requests for the JDK Project. Author requests should be straightforward, and thus should not induce significant delays. As the JDK Project Lead, Mark said that he reviews Author requests a couple of times each week. It has been rare for fulfillment to take more than one week, but sometimes it does take longer. In a recent case, for example, a Contributor from China used a different romanization of their name than they had used when submitting their signed Oracle Contributor Agreement (OCA), so it took longer to verify that they had signed that agreement.

Andrew suggested publicly setting expectations for the timing of Author requests, and thought that the minutes would sufficiently address this need. After a brief discussion about who handles requests when Mark takes time off, Mark acknowledged that there is no acting Registrar in his absence, though there should be.

2. JEP Process issues

Georges opened this topic by anticipating the first issue related to the JEP Process. The process has been revised several times, and is now at version 2.0. The description of that version has been in the draft state for several years now but is, in fact, actively in use. It is not yet final because some of the text does not match reality. It is a challenge for contributors to work with the process if they are not already familiar with it. Andrew agreed with this summary. He added that the general sense is that the JEP process works well, once you know what to do. A great virtue of the process is that JEPs provide an historical archive which documents significant changes. Transparency is missing, however, around why some JEPs do not progress through the process. He noted that it is not obvious, for example, that going from the Submitted to Candidate states requires a judgement call from various people.

Mark apologized for not yet having merged the JEP 2.0 process document into the main process document. All of the relevant information is present, but it is difficult for a reader to know which portions of the text are current and which are obsolete. He said that he would, within the next few months, post a finalized JEP 2.0 process document for the usual one-week review period.

Moving to the second issue around JEPs, Andrew said that the experience of some JEP authors who are new to the OpenJDK Community is that calling attention to a new JEP is rather like shouting into the void. You need to know which people to talk to, and proactively solicit them. Many experienced Contributors are quite good at providing prompt and thorough feedback. There have been cases, however, where a JEP presents a neat idea which will cause all sorts of problems, but nobody provides any feedback.

Mark observed that while it is great to see new Contributors bring fresh energy and enthusiasm to the Community, submitting a JEP is just about the most difficult way in which to make a first contribution. Georges noted that providing detailed feedback on a JEP can take an amazing amount of time. Experienced Contributors can be reluctant to invest such time since well-intentioned yet negative feedback that disappoints JEP authors has sometimes resulted in anger and frustration. Andrew suggested that, given all this nuance, a companion document, "So you think you want to write a JEP," would be useful. Mark was reminded of Karen Kinnear's JVMLS 2018 talk, Just a Small Class File Change — Nestmates: A Case Study, saying that it was a fantastic description of what is actually involved in integrating a new feature into the JDK.

At this point, Christian joined; Samir departed, citing a conflict and expressing eagerness to review the minutes soon. Georges briefly summarized the prior discussion for Christian and then the JEP conversation continued.

Georges observed that there seems to be an expectation that candidate JEPs have received sufficient scrutiny to be nearly ready to integrate into the JDK. The original intent of the process was that candidate JEPs can be good ideas that have not yet necessarily been investigated deeply. Mark agreed with this characterization, noting that moving a JEP to the Candidate state only requires the consensus of a few Reviewers. A JEP can sit in that state for years without any commitment for it to proceed further; to move it forward, the JEP's owner needs to build further consensus. Mark suggested that it might be worth reviewing all the old candidate JEPs to see if any should be withdrawn. Georges' perception was that Contributors are somewhat loath to propose a JEP until they have quite a significant understanding. Mark added that when the process was originally conceived, the intent was for the set of candidate JEPs to serve as a medium-range, three-to-five year technical roadmap. In practice, however, JEPs frequently enter the Candidate state just two months prior to the Rampdown Phase 1 (RDP1) milestone of their anticipated target release. He views this as a problem that he does not know how to fix.

Chris asked whether the problem was lingering candidate JEPs or late candidate JEPs. Andrew replied that while he had been lobbied to bring this issue to the Board, he personally felt that the process could be slicker. It was not clear how much friction there should be, but some is good for the sanity of everyone who uses Java. In Chris' experience, working both at Oracle and Twitter, the need for a JEP sometimes led Contributors to complain that the required paperwork takes too much time; Mark observed that the perception of the overhead of the JEP Process is different in different areas, with Contributors in some areas finding it less onerous than those in others. Chris wondered whether JEPs should be filed earlier; Georges said that JEPs have fairly low friction to propose, but higher to move forward, by design. He suspects that people mistakenly believe that a JEP reaching the Candidate state constitutes a guarantee that it will be integrated into the JDK fairly soon. Chris noted that some are reluctant to submit JEPs because doing so can lead to endless discussion without hope of resolution; Mark observed that since the OpenJDK Community operates by rough consensus, discussion is necessary. He expressed hope that, once the JEP Process is updated to version 2.0, he can emphasize the value of submitting JEPs earlier.

After Andrew confirmed that the trio of JEP subtopics has been covered, Georges moved discussion to the next agenda item.

3. Vulnerability Group infrastructure

Andrew introduced this topic by saying that he did not think that it strictly fell within the purview of the Board, but that it was worth raising in this forum anyway. A Contributor's participation in the Vulnerability Group requires signing the OpenJDK Vulnerability Group Non-Disclosure and License Agreement, which is an agreement between Oracle and the Contributor. That agreement requires all communication to occur via encrypted e-mail, but sharing vulnerability patches via encrypted e-mail is tedious and painful. While Andrew understands that some kind of patch server or shared source-code repository would be a target for adversaries, encrypted e-mail itself is not without risk. He wondered whether there are more sophisticated means of sharing information that would be low risk but more convenient.

Mark agreed that changing the agreement was something that only Oracle could do, and doing so would require extensive consultation similar to the multi-year discussions that took place when it was first created. He personally thinks that finding a better means to share patches and other sensitive information is appealing.

At this point, Georges noted that he was due to host another meeting. He thanked Andrew for the rich set of agenda items and the Board in general for attending. Finally, he reminded everyone to expect draft minutes for review within a week.

At this point, the Board adjourned.