[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec.committee] Certification Requests for Specifications with no TCK
|
I did not get this from the call. What I understand from our rules is that if you want to make a claim of compatibility against spec X then you do need to make a CR against the spec project for tech X. Tech X is responsible for the X TCK and verifying requests. Today’s spec X’s TCK may be in the platform and this may result in a rubber stamping of the request, but ultimately the spec is responsible for producing the TCK and being able to validate certification requests against it.
> On Sep 4, 2019, at 6:26 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>
> Where we left this topic to day is still unclear to me. Here's what I understood from today's call:
>
> - Must GlassFish file a certification request with the EJB project: yes, cause rules
> - Must OpenLiberty file a certification request with the EJB project: no, cause they don't want to
>
> I've filed and approved a request on behalf of the GlassFish project so my part is done:
>
> - https://github.com/eclipse-ee4j/ejb-api/issues/56
>
> My primary position on today's call was we should be honest with ourselves on if a rule is providing enough value to be worth it. IMO, rules are a form of technical debt. When we say one thing and immediately do another, it's a sign the debt isn't (yet) worth it.
>
> My ambitions commonly outpace my actions, so it's something I aggressively watch for. Probably still not enough :)
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>> On Aug 26, 2019, at 5:42 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>>
>> We appear to have been inconsistently handling now we're supposed to handle certification for Specifications with no TCK.
>>
>> Kevin filed for both the Spec and Platform:
>>
>> - https://github.com/jakartaee/specifications/pull/75
>> - https://github.com/jakartaee/specifications/pull/19
>>
>> Arjan did it only for the Spec and not the Platform:
>>
>> - https://github.com/jakartaee/specifications/pull/52
>>
>> I did it only for the Platform and not the Spec:
>>
>> - https://github.com/jakartaee/specifications/pull/91
>> - https://github.com/jakartaee/specifications/pull/36
>>
>> We should discuss this Wednesday. Open questions using Interceptor as an example:
>>
>> - Is the Interceptor spec project, for example, supposed to evaluate all the CTS results or just the interceptor tests?
>> - If the full results, is the Interceptor project supposed now completely understand full CTS certification requirements?
>> - Can you call yourself Interceptor-certified if you pass just the Interceptor tests?
>> - What would it mean if say the Interceptor project rejected the full CTS certification but the Platform accepted the same results?
>> - What is the value this brings for the overhead it creates?
>>
>> For Managed Beans it is particularly odd as we're filling the same request twice in the same project to be evaluated by the same people.
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>>
>>
>
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
