I thought I would put together a summary of the changes for our spec leads to comment on to help solicit feedback on the JSR-348 JCP v2.8 public draft. These changes are relative to the current JCP2 Document, v2.7 (May 15 2009). The headings below are from the v2.8 JCP public review document, and terms in bold are from the v2.8 Definitions section.
Note that the JSR-348 public review ends on Sep 6, 2011, so make sure you have your comments recorded either view the mailing list, or issue tracker by then.
I Executive Summary
The two ECs representing the embedded and server spaces will likely be collapsed into one.
The four steps of a JSR are slightly tweaked to have step 2 be "Draft Releases" vs the v2.7 "Early Draft" phase to emphasize that any number of drafts can be put out to encourage feedback from the community. Step 3, "Final Release" vs the v2.7 "Public Draft" phase clarifies how a draft becomes the final proposal and requirement for an TCK and RI that passes the TCK. This emphasizes that the RI and TCK must be completed before the final draft can be submitted to the EC for approval.
II Definitions
The section covering definitions of terms used in the process document have been greatly expanded by pulling in all of the definitions spread through the v2.7 process document into one section.
1.1 EXPERT GROUP TRANSPARENCY
Having a JSR EG work in a completely transparent manner is a major focus of this v2.8 rev of the JCP. While the v2.7 rev did encourage transparency, it was not required. In v2.8, EGs must operate in a transparent with public channels with public responses to all input. How this will be accomplished must be specified in the JSR submission.
1.1.1 MAILING LISTS
All substantive business must be carried out on a public mailing list in the v2.8 process. This was only encouraged in v2.7.
1.1.2 ISSUE TRACKING
Issues must be track through a publicly readable issue tracking mechanism in the v2.8 process, with all formal comments entered as issues, and all issues must be publicly responded to before a JSR can go on to the next phase. There was no requirement for issue tracking in v2.7.
1.1.3 CHANGES TO LICENSING TERMS
There are stronger requirements to maintain the initial RI and TCK licensing terms. If a change to the RI and TCK is approved, the original licensing terms published at the time of Final Release must continue to be offered.
1.2.2 DISRUPTIVE, UNCOOPERATIVE OR UNRESPONSIVE EXPERT GROUP MEMBERS
The process for dealing with EG members that are not contributing has been simplified and strengthened. Any three members of the EG can approach the Spec Lead and request that the EG member in question be excluded from further participation in the EG. If the Spec Lead agrees to the request he can then do so.
1.2.3 UNRESPONSIVE OR INACTIVE SPEC LEAD
New to the v2.8 process document is the notion of an unresponsive spec lead and the process by which they may be replaced.
1.3 JSR Deadlines
A number of deadlines from the initial JSR Approval Ballot (JSR Approval) have been introduced to ensure a JSR proceeds at reasonable pace through the various phase. A JSR must:
- begin Early Draft Review within the first 12 months
- begin Public Review within 2 years
- achieve Final Release within 3 years
otherwise, the EC should initiate a JSR Renewal Ballot unless it is agreed that there are extraordinary circumstances that justify the delay.
1.4 COMPATIBILITY TESTING
The Spec Lead is responsible for defining the process whereby the TCK is used to certify implementations of the JSR as compatible. The Maintenance Lead must submit to the PMO at least quarterly, and at every Maintenance Release, a list of all implementations that have been certified as compatible and that have been released publicly or commercially. If the Spec Lead submits the information in the form of a pointer to an already published list the PMO may choose simply to reference that list rather than duplicate it.
TCK license terms must permit implementors to freely and publicly discuss the testing process and detailed TCK test results with all interested parties.
1.7 ESCALATION AND APPEALS
v2.8 introduces an escalation/appeals process where any EG member can appeal to the EC regarding a decision, an action or inaction by the PMO, a Spec Lead, or a Maintenance Lead that affects EG participation or issue-resolution and which cannot be resolved by other reasonable means.
3.1 WRITE THE FIRST DRAFT OF THE SPECIFICATION
3.2 EARLY DRAFT REVIEW
This is largely the same between v2.8 and v2.7, but there is an emphasis on the fact that multiple iterations of the Early Draft/Early Draft Review phases can be utilized if an EG believes that would be helpful.
4.1.2 ESTABLISH A FIRST-LEVEL TCK APPEALS PROCESS
This is the same as in v2.7, but the reference to a full TCK appeals process has been dropped in favor of a simplified description of how to escalate the appeal to the PMO and EC, which may trigger a TCK Appeal Ballot.
4.1.3 UPDATE THE DELIVERABLES IN RESPONSE TO THE APPEAL BALLOT
v2.8 includes a section on the need to update one or more of the TCK, the Specification, or the RI. Within one month of the close of a successful TCK Appeal Ballot the Maintenance Lead must update these deliverables as necessary and record the changes in the relevant sections of the Change Log.
4.2 FINAL APPROVAL BALLOT
v2.8 unifies the complete TCK compatible implementations requirments by including the following conditions from the JSPA:
a) fully implement the Spec(s) including all required interfaces and functionality, and
b) do not modify, subset, superset, or otherwise extend the Licensor Name Space, or include any public or
protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other
than those required/authorized by the Spec or Specs being implemented.
and, requires that in addition to 100% signature test coverage, no non-specified APIs are included in the JSR's namespace.
4.3 FINAL RELEASE
v2.8 add the requirement that a means to obtain the TCK documentation at no charge must be published. Further, a requirement to maintain the links to the RI and TCK must remain valid through the life of the JSR, or the JSR is subject to reversion back to the Proposed Final Draft or Maintenance Review stage as appropriate, and would have complete the Final Release or Maintenance Release process again.
5.2 MAINTENANCE REVIEW
v2.8 has simplified the maintenance process, which now requires the use of an issue tracker to gather items for consideration for inclusion in the revision.
6.3 EC DUTIES AND RESPONSIBILITIES
v2.8 expands the v2.7 EC duties in 3 areas:
- Review and provide guidance on proposed licensing terms of proposed JSRs.
- Ensure that publicly expressed issues/concerns with a JSR are addressed by the Expert Group.
- Decide when JSRs that have not made sufficient progress through the Process should be withdrawn.