[JSR358-31] Strengthen TCK quality requirements Created: 06/Jul/12  Updated: 12/Dec/12

Status: Open
Project: jsr358
Component/s: TCKs
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Process Document contains language intended to ensure TCK quality, but this is typically not enforced.

EC members have an obligation to review TCKs for quality before voting their Final Approval, but many do not.

Should we enforce or strengthen TCK quality requirements?



 Comments   
Comment by lightguard [ 20/Jul/12 ]

How would you propose we go about doing this? Seems like a tool would be useful. Perhaps something like what was done for CDI? http://docs.jboss.org/cdi/tck/reference/1.0.1-Final/html_single/#d0e791

Comment by ebresie [ 12/Dec/12 ]

Hope this is not out of scope...

To me Quality requirement implies a requirement is implemented as expected.

TCK seems more low level "Unit Test" level as opposed to higher level "Acceptance Test" level. Acceptance testing may have some overlap with unit test but they are still slightly different.

Maybe the Spec could better spell out the Acceptance criteria requirements.

Or maybe some form of TCK (Acceptance Test Plan) Spec with Acceptance requirements defined could help. Drawback is could potentially add extra "work" to the mix, but this could potentially allow "clean implementations" to implement there own TCK relative to the TCK Spec requirements.

Comment by ebresie [ 12/Dec/12 ]

I assume this is address by other non-implementer involvement, but there may still be some bias among participants.

Should an "independent" participant not involved in the group be considered to insure quality? Maybe a Quality EG?





[JSR358-40] JSPA 5.F.IV, drop or modify scope of exemption for Oracle RI/TCK licensing Created: 23/Aug/12  Updated: 23/Aug/12

Status: Open
Project: jsr358
Component/s: Licensing, TCKs, Transparency
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: starksm64 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In section 5.F.IV of the JSPA from

Notwithstanding the foregoing, neither this subparagraph IV nor Section 5.F.II (concerning reciprocal patent licensing, shall be understood to require Oracle to modify license agreements for Java technology that Oracle has in place, or to modify or replace in future license agreements for Java technology provisions comparable to those currently in place, where the RI and/or TCK would be covered by such license agreements. This proviso shall not be understood to exempt Oracle, when it is the Spec Lead, from the obligation to license the TCK separate from the corresponding RI code when the Spec is developed under any JSR submitted hereafter.

I would argue this is unnecessarily broad and should be dropped in the spirit of transparency as one cannot understand that ramifications of the statement by reading the available JCP documents.



 Comments   
Comment by starksm64 [ 23/Aug/12 ]

Section 6.C makes a similar statement regarding section 6.

C. Effect on Existing Agreements. No provision of this Section 6 shall be understood to require Oracle to modify license agreements for Java technology that Oracle has in place, or to modify or replace in future license agreements for Java technology provisions comparable to those currently in place, with respect to Oracle’s granting of license for (or covenants not to assert) its patent claims where there is no technically feasible alternative that would avoid the infringement of such claims (with respect to Your exercise of the rights described in Section 6.A.[a]-[c]).





[JSR358-92] Create a standard Community TCK License Created: 07/Mar/15  Updated: 07/Mar/15

Status: Open
Project: jsr358
Component/s: Licensing, Participation, TCKs
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: pcurran Assignee: pcurran
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Create a standard Community TCK License modeled on the OpenJDK Community TCK License Agreement (OCTLA).

This license would grant access to the TCK to all participants in a JSR's collaborative RI-development project.






Generated at Fri Feb 12 22:06:09 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.