 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Executive Committee Meeting Minutes
|
|||||||||||||||||||||
|
|
PMO | |
| |
|
ME EC |
SE/EE EC |
Total attendance: 13 |
Total attendance: 15 |
| Since 75% of the ME EC was present, that EC was
quorate for this meeting Since 75% of the SE/EE EC was present, that EC was quorate for this meeting | |
|
PMO | |
| |
|
ME EC |
SE/EE EC |
Total attendance: 12 |
Total attendance: 13 |
| Since 75% of the ME EC was present, that EC was
quorate for this meeting Since 75% of the SE/EE EC was present, that EC was quorate for this meeting | |
The ECs discussed the public minutes from the previous December meeting. Don Deutsch pointed out that the ME EC was not (at the time of the discussion) quorate and that it would therefore be inappropriate to approve the minutes. After some discussion, EC members agreed that in future minutes should be reviewed, corrected (if necessary), and approved by mail rather than in EC meetings, in order to avoid this problem.
Later in the day, when the ME EC became quorate, the minutes were discussed again and were approved.
Patrick delivered the EC stats presentation.
Patrick reported that Pardeep Khowash is the new alternate representative for AT&T.
Patrick presented year-end statistics, discussing the number of JCP members and the election results, and providing details of active JSRs, Spec Leadership, and Expert Group membership. See the presentation for details.
During discussion, it was noted that the number of active JSRs was down slightly, but not significantly, from the previous year. It was suggested that data on "un-deployed JSRs" (JSRs that have been completed, but which are not implemented commercially) would be interesting. Also, members suggested that we investigate the "slow JSRs" further, and provide an average of the completion times. Heather reported that the PMO is in the process of reviewing recently-completed JSRs, and that the investigaions would focus particularly on cases where the JSR took an unusually long (or short) time to complete.
Patrick provided some additional historical data showing the rate of submission and completion of JSRs over time. Members pointed out that a decline in the number of new JSR submissions should not necessarily be interpreted as a problem, since as the platforms mature it would be expected that fewer new JSRs would be filed. Additional data on the number of maintenance releases would help to clarify the situation (these could be expected to increase over time.)
Heather Vancura summarized the current situation with Inactive JSRs (see presentation) and members discussed what steps should be taken to ensure that these JSRs are either withdrawn or revitalized. EC members noted that there are a significant number of JSRs that have made no progress - often for several years - since the Expert Group was formed (or claimed to be in the process of formation), and suggested that the PMO focus on these initially, encouraging the spec leads to withdraw them.
The PMO agreed to do so, and representative from EC member companies agreed to help with JSRs whose spec leads work at their companies.
The PMO promised to report on progress at future meetings.
Bob Lee from Google led a discussion on JSR 330, focusing on factors that helped the Expert Group complete this JSR in record time. He emplasized the importance of working in the open (with public mailing lists and issue-tracking) and of doing all the work by email, discouraging private conversations. He pointed out that the majority of the work had been completed before the JSR was filed, noting that it might have been more difficult to handle contentious issues within the JCP process. Josh Bloch agreed, arguing that it is best to resove contentious issues before filing a JSR.
Other "best practices" include focusing on a relatively constrained area, and recruiting a highly motivated, skilful, and diplomatic Spec Lead.
Recommendations to the PMO included encouraging more transparency, and providing public issue tracking.
Heather noted that the PMO is conducting case studies in agility, and promised to report back to the ECs.
EC members tentativly confirmed the 2010 meeting schedule, agreeing that the East Coast face-to-face meeting be held at AT&T's premises in Atlanta, Georgia, while the European meeting would be hosted by Deutsche Telekom/T-Mobile in Bonn. Members agreed to discuss by email the possibility of changing the May date to enable more members to participate.
Alex Buckley gave a presentation on JSR 294 and transparency. During this presentation he suggested that some kind of incubator process, mandating a formal scoping exercise before JSRs are filed, would be helpful. He suggested that the process should mandate publicly readable and writeable observer lists.
He also pointed out the importance and difficulty of engaging with "casual observers" - those who comment on a JSR in blogs or elsewhere outside of the "normal" discussion forums.
Finally, EC members discussed the importance of having a "Contribution Agreement" to ensure that those who participate in a JSR in a more casual manner (that is, not as members of the JCP) formally assert that they have the rights to the IP that they contribute, and make a formal grant of that IP. See the JSR 294 Observer license for details.
Three EC members with experience of incubator processes in other standards-developing organizations provided an introduction to how these organizations implement such processes:
Don Deutsch explained the Patent Policy options that W3C incubator groups must choose from. Option one involves no licensing commitments by participants. Under option three all particpants agree to abide by the W3C Patent Policy for any work transitioned to the Recommendation Track. Option two effectively gives each participant the freedom to chose which of the other two options they will abide by.
Ten or eleven incubator groups have been formed and a small number had progressed to become formal Working Groups. The incubator groups are approximately evenly split between the first and the third patent option. Groups that were formed simply to gather data or to perform research typically chose option one, while groups that hoped to move on to develop formal specifications typically chose option three. (None chose option two.) Don noted that the W3C had underestimated how important IP issues like these would be. Patrick noted that these issues are similar to those the JCP has been grappling with around contribution agreements and Terms of Use for participation in discussion forums.
Calinel asked how successful the whole incubator process had been, and Don responded "not very." Danny asked why anyone would work through the W3C rather than simply creating their own public mailing list for discussion. Don pointed out that the W3C provided a ready world-wide audience.
Don noted that the primary reason for defining the incubator process was to permit W3C activities while limiting the expenditure of staff resources (formal Working Groups must be assigned resources). He pointed out that the JCP would not have this problem since it makes no commitment to assign staff resources to Expert Groups.
Mike Milinkovich then presented an overview of the Eclipse incubation process (see slides.) He said that the process was inspired by the Apache foundation, but differed from Apache somewhat, since for Eclipse the incubator is a state whereas for Apache it is a place. Every Eclipse project starts in the incubation state, and the development of a statement of scope is a significant aspect of the process. The incubation process is "training wheels" for an Eclipse project. Expectations are lower than for fully-mature projects, and this is an opportunity for project members to learn the process and to make mistakes. The requirement to find two "mentors" from among the Architecture Council (which has 40-50 members in all) helps to filter out impractical projects. There are few IP issues since all Eclipse projects use the same license and adopt the same IP policy.
The process of "graduation" from incubator state typically involves a formal review. Releases are now labeled 1.x, and APIs are considered permanent. Projects are now expected to have mature and development, build, and release processes. While 10-15% of projects never progress beyond the incubation state the majority do graduate, some in only a few months while others take longer.
Patrick pointed out that if the JCP had a similar incubation state this would resolve the problems with JSRs that never progress beyond the Expert Group formation stage.
Finally, Geir Magnusson provided an overview of the Apache incubator process. This was created to ensure that code donations to Apache were legaly appropriate, and to ensure that projects follow Apache processes and principles. He noted that there are many similarities to Eclipse incubators, but that at Eclipse the process is more top-down (with the Board having significant influence) whereas Apache is more bottom-up (the project has significant autonomy.) As with Eclipse, the primary purpose is to ensure that the project is ready to take off, and as with both Eclipse and W3C, patent grants are covered by the incubator process.
Members then discussed the implications of an incubator process for the JCP.
It was pointed out that the JCP's lack of a standard licensing model might pose
difficulties since uncertainty about the eventual licensing model might deter
people from participating in an incubator project.
John Rizzo asked
whether incubation was just another stage at the beginning of the process. Mike
DeNicola pointed out that mentoring was an essential component of the Eclipse
and Apache incubation processes. Steve Wolfe noted that many Spec Leads expect
to make commercial gains from their activity. It was therefore suggested that
incubator processes might apply only to Open Source projects.
Danny
Coward pointed out that an incubator process might increase the chances of an
Expert Group succeeding, and would eliminate the "surprise factor" as EC members
have only a two-week period to decide whether to support new JSRs.
Wayne
Carr noted the "Gold Rush problem," whereby those who stake a claim to
"territory" by filing a JSR are then considered to own that
territory.
John Rizzo argued that if an incubator process is introduced
it should not require an additional vote.
Josh Bloch asked whether we
should allow multiple incubator projects in the same space. Geir Magnusson said
yes - we want the best technology, not the first to be proposed.
Scott
Stark argued that any discussion of incubators is premature, and that the larger
JCP process issues should be resolved first.
[The EC adjourned for the
day, but agreed to pick up the discussion the following morning. The notes below
are from the next day's discussion.]
The follow-on discussion quickly
moved on from incubators to a broader discussion of licensing issues. John Rizzo
argued that a complete overhaul of processes and licensing models was needed.
Ideally, a unified licensing model would be introduced. Josh Bloch argued for a
permissive BSD-like license. Others argued that this would not ensure that
people who make changes to a technology would give them back to the community,
as the GPL requires.
Wayne Carr and others pointed out to new members
that the EC has had extensive discussions about similar licensing suggestions in
the past (with particularly important resolutions passed at the "meeting in the
barn" in December 2007). They noted that much of the investigation being
proposed had already been done and probably didn't need to be repeated. With the
Oracle acquisition pending and expected to be determined one way or the other
shortly, it was decided to postpone the discussion.
Tim Peierls suggested
that the EC present Oracle with an explanation of the changes they would like to
see in the organization. There was no consensus to do so, but after the meeting
Wayne Carr circulated by email a summary of previous discussions.
Werner Keil gave a presentation on JSR 275. Members expressed a variety of concerns about the design approach taken by the Expert Group, including naming issues and a possible overlap with JSR 310: Date and Time APIs. (JSR 275's Public Review Ballot was scheduled for the week after this EC meeting. In that ballot many EC members expressed their concerns by voting "no" and the ballot failed. See the results for details.)
Paul Su from Aplix gave a technical overview of MIDP 3, followed by a demonstration. See the presentation for details.
Sean Sheedy gave a brief status report from the ME Working Group. It was decided that the next meeting would be in two weeks.
Patrick introduced this discussion by pointing out that there are increasing
calls for a merge of Java ME and SE, that modularity is being introduced in Java
SE, and that profiles have been introduced in Java EE. What are the implications
of these trends for the work of the JCP, and for the broader issues of
compatibility?
Doug Lea pointed out that it is often difficult for
technologies to "piggy back" on top of the core. Different rules are required
for the base. Dependency management, and new testing strategies are required.
Patrick responded that the Java EE CTS is being modularized into component
TCKs.
Roberto said that Java EE is taking things slowly, and so far has
introduced only one profile.
Alex Buckley noted that the JDK is
being physically broken into smaller pieces, but unless a module system is
actively invoked the user of the system will see no difference (the platform
will still be "complete.")
Patrick argued that once modularization is
enabled, subsetting is inevitable. Tim Peierls noted that the RESTlet community
has a common code base but builds for multiple environments (Java SE, Java EE,
Android, Google GWT, etc.)
Patrick asked whether modularity might result
in fragmentation. John Rizzo argued that this is not inevitable. In the ME space
the problem is not the existence of "modules" but rather incompatibilities in
implementations - optionality is beneficial. Danny noted that we have
significant "fragmentation" between Java SE and Java ME (ME is a subset of an
early version of SE, and the two have since diverged.) The API, and language
subset in Java ME should be consistent with Java SE. Wayne Carr pointed
out that it is difficult to create optional specifications that run on
both platforms.
Patrick argued that optionality endangers
interoperability.
Alex Buckley pointed out that if so, this is a failure
of dependency management. In a well-designed system requirements are documented
and missing components would be downloaded (or could be manually installed.)
Steve Wolfe asked whether JSR 294 implements such a dependency-management
system. Alex responded no - it enables such a system, but the Expert Group did
not want to "tread on the toes" of any individual module system. Steve asked
about the dangers of incompatibilities between the behavior of modules as the
interact with different environments. Alex responded that this can be handled by
versioning on top of dependencies. Compatibility is well
understood.
Wayne pointed out that modularization doesn't necessarily
mean a free-for-all. Profiles will be defined. Josh argued that making the
compatibility tests freely available would help.
Steve Wolfe asked who
defines modules? John Rizzo responded that in Java ME individual JSRs define
modules, and then there are "umbrella JSRs" that define stacks (profiles.) He
noted that for Java ME the issue of royalties owed per JSR was an obstacle to
the implementation of a real module/dependency-management system. Scott Stark
pointed out that this is soluble. A factory method could be designed to fail if
the appropriate license was not present.
Steve Wolfe asked who decides
the level of granularity with which APIs are exposed and modules defined. Don
Deutsch asked whether the platform-subset issue is confined to Java ME and Java
SE. Danny responded "no", since Java EE depends on the entire Java SE platform.
Roberto noted that Java EE might prefer a smaller base, and he noted that the
influence is two-way, since Java EE specifies requirements for Java
SE.
Doug, Patrick, and Scott argued that dependency management is a good
thing, that TCKs must be aware of dependencies, and that specs should explicitly
call out dependencies.
After thanking Sun and Heather Vancura of the PMO for hosting and arranging the meeting, the ECs adjourned.
