Re: [jakarta.ee-spec.committee] Point before proceeding with changes

[David Blevins <dblevins@xxxxxxxxxxxxx>]

I don't believe we validly obtained any TCK results because they were run with non-final TCK binaries that are not the ones we will eventually vote on.

One of our bottlenecks is that we need to get proposed final TCK binaries that will receive no further tweaks.

I understand we are all thinking "finish line", but we also need to think about what example we're setting.  If NoSQL came to us and asked us to vote on their final spec and the status quo they brought to us was a TCK still being tweaked, test results from a snapshot, and thin details on their first compatible implementation, then we should tell them they haven't met the minimum requirements and are not eligible for a vote.

We can't do that if we ourselves break the rules.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Jul 24, 2019, at 12:17 PM, Scott Stark <sstark@xxxxxxxxxx> wrote:
> 
> Not if that can all be easily obtained from the current CI TCK runs.
> 
>> On Jul 24, 2019, at 12:11 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>> 
>> Let's put terms aside, because I think we quickly make ourselves dizzy with chicken/egg.
>> 
>> Here's the information we require from people who claim to have passed the TCK:
>> 
>> - Product Name, Version and download URL (if applicable)
>> - Implementation runtime Version(s) tested
>> - Java runtime used to run the implementation
>> - Summary of the information for the test environment, operating system, cloud, ...
>> - Specification Name, Version and download URL
>> - TCK Version, SHA-256 fingerprint and download URL
>> - A statement attesting that all TCK requirements have been met, including any compatibility rules
>> 
>> Is there anything here that is particularly onerous to require of the first claim?
>> 
>> 
>> -- 
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>> 
>>> On Jul 24, 2019, at 10:22 AM, Scott Stark <sstark@xxxxxxxxxx> wrote:
>>> 
>>> So to be clear, the addition of a request for certification as a demonstration of the existence of a compatible implementation is not a requirement that I can see in our current process or guides. We would not have voted for a process that requires validation via certified vs compatible implementations. There is nothing wrong with using an open source project that passes the TCK that has no desire to become a certified implementation. Certification is more aligned with supported products that have release schedules that lag their upstream counterparts.
>>> _______________________________________________
>>> 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
>> 
>> _______________________________________________
>> 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
> 
> _______________________________________________
> 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