Governing Board Minutes: 2011/8/25

The OpenJDK Governing Board met via conference call on Thursday, 25 August 2011 at 15:00 UTC with the following agenda:

  1. Census and Bylaws
  2. Process update
  3. Infrastructure update
  4. JDK 7 Updates Project

Three Board members were present at the start: Jason Gartner, Adam Messinger, and Mark Reinhold. Doug Lea joined the call about five minutes late.

Two Observers were present: Andrew Haley and Georges Saab.

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.

1. Census and Bylaws

Mark reminded Board members that he sent the Census to them for review two weeks ago. The Census represents the implementation of Appendix B of the Bylaws, which requires an accounting of who is associated with each Project and Group. Record-keeping during the early years of the OpenJDK Community was unfortunately somewhat lax, so census data had to be reconstructed from mailing-list archives and Mercurial repository histories. Mark thanked Iris Clark for having done that reconstruction.

Adam asked what the policy was for membership renewal. Mark replied that the one-year renewal requirement is only relevant to OpenJDK Members. Jason recommended that there be an effort to clean up OpenJDK membership one year from now. Mark emphasized that mailing-list subscriptions would not be part of that clean up, just OpenJDK Group and Project roles. Adam suggested that inactive individuals be sent an invitation to become more active participants in OpenJDK. OpenJDK Members should be reminded that their membership expires annually. Mark noted that in many cases, valid e-mail addresses for inactive people are not available.

At this point, Doug joined the call.

AGREED: The Census will not attempt to reflect only individuals who are active in OpenJDK. The Governing Board reserves the right to drop such individuals in the future, and will consider Adam’s recommendation to contact those individuals directly.

Mark asked for any specific feedback on the details of the Census; there was none. Mark said that if there were no objections, he’d publish the Census on Monday. He then requested recommendations for the review interval, noting that 2 weeks was typical.

AGREED: The Census review period will be 2 weeks.

2. Process update

Mark noted that the JEP process was posted yesterday and was now up and running. He expected to see JEPs start flowing in, at least from developers at Oracle. Georges explained that JEP submission is intended to be an on-going practice which should be encouraged. It is expected to aid release planning by building a pipeline of ideas which can be explored over a longer period of time than a single release cycle. That way a release can be planned by considering which features in the pipeline might be ready in time, rather than by coming up with new features for a release only when the planning for that release begins.

Andrew observed that there seemed to be overlap between the JCP and JEPs, and wanted to know how they interacted. To put things into perspective, Georges offered the example of JDK 7. In that release, had the JEP process been in place, approximately 100 features would have had JEPs. Georges explained that JEPs should be used for discussing an idea without any initial commitment about when and if it might become a feature in an actual release.

Doug remarked that JEPs seemed very Oracle-centric and did not accommodate the common form of contribution. Mark reiterated that the goal of the process was to bring transparency to all of the work being done for JDK Release Projects, since these releases are not small efforts and require extensive planning. Georges added that development is bottom up, while funding is top down. Doug wondered who would be handling all of the paperwork. Mark responded that most small changes would not require a JEP. Doug attempted to determine the boundaries of the need for a JEP by offering various scenarios. Mark explained that JEPs are typically required for changes requiring more than two weeks of work; there are, however, conceivably some cases (e.g., a brand new sorting algorithm) which require less time, but might require a JEP to ensure visibility. Mark provided another example: The fork-join work in JDK 7 would likely have required a JEP.

Georges stated that, going forward, JEPs would be submitted and reviewed on a regular basis. The JEP process is being bootstrapped during JDK 8. Per Plan B, JEPs will be funded and targeted to JDK 8 based in part on which features can fit alongside Jigsaw and Lambda. A light-weight process is still needed by which developers can provide status on funded JEPs during development so that early warning can be given if problems arise.

Adam solicited feedback from Jason and Andrew. Jason echoed some of Doug’s point of view, but said he didn’t have to squint very hard to see how IBM could work with the JEP process. (IBM’s rough threshold for significant features is “bigger than a bread box” rather than two weeks of development time.) Overall he’s in favor of JEPs since they fit into overall the spirit of the OpenJDK Community. Andrew noted that the means of providing feedback could be improved but he thought that the best course of action was to proceed with the process and review it later to identify any potential improvements.

3. Infrastructure update

Georges presented a set of slides that Mohan Pakkurti (Oracle) prepared. Georges highlighted slide 3, which provides the current status including the decision to use JIRA and sets the expectation that a pilot will be used for two OpenJDK Projects, Jigsaw and Lambda, and to model scalability and performance. Slide 4 outlines Oracle’s resource commitments to this project. Finally, there are slides providing a rough timeline for the project.

Doug was generally disappointed that this would take some time and predicted that it would take more time than anticipated. Georges empathized but asserted that this was a large, complex project that needed to be done correctly to achieve the goal of making everybody’s lives easier.

4. JDK 7 Updates Project

Andrew observed that the JDK 7 Updates Project did not seem to have a clear plan. Mark asked whether he’d consulted the Project Lead, Dalibor Topic. Doug replied that the Lead was not obvious. General conversation followed. The primary recommendations were that the Lead be more visible, particularly on the Project page, and that a timeline be posted.

Several people had questions regarding the content decisions for the update releases, and their schedules. Georges explained that JDK 7u1 is scheduled for October and will contain security fixes plus a small set of high-priority items. He also mentioned that since 7u1 contains security fixes, content decisions were not strictly made by the Project Lead. JDK 7u2 is scheduled for December. Doug requested information for how to get additional changes into 7u1. Mark responded that the bar would be quite high (i.e., hair-on-fire).

At this point the Board adjourned.