| The license is completely deferential to the requirements of the TCK. I have updated the current User guide requirements section of the TCK process guide to include:
The license requires satisfying all requirements of the TCK.
The TCK Users Guide includes a set of requirements.
If we want everyone to submit a certification request, we can add
that requirement to the TCK Users Guide, which then ties it to the
requirement in the license:
- Before any claim of compatibility may be made, a certification
request must be submitted and approved per the process described
at <link>.
So, I agree with David, and the above is the way to accomplish
that. And the certification request must be filed before sending
email to tck@xxxxxxxxxxx.
(I really wish we had fleshed out this process before
writing the EFTL...)
David Blevins wrote on 6/21/19 12:31
PM:
I heard agreement between you, Kevin, Bill and myself that it was
reasonable for us to include in the TCK Guide that a
`certification` issue must be filed in accordance with the TCK
Process document. Can any of you speak up if this is not the
case?
Reminder that TCK Process
document is where we have defined the minimum TCK
requirements, including what must publicly be disclosed as
"results" per
section 2.b of the license.
TCK Process document not only
defines the information that must be disclosed as results,
but also allows the Specification project to define
additional information such as publicly disclosing what
database they tested on, what OS, etc. We discussed this at
great length in Feb and March.
If the Specification Committee
does not have the authority to define the TCK requirements
as per section 2.a and what public results mean as per
section 2.b, we don't need a TCK Process document.
It is my understanding we do
have that authority and therefore emails to tck@xxxxxxxxxxx must satisfy
our definition of public test results and therefore cannot
logically happen before filling the appropriate Github issue
with the required information.
Is there any disagreement with
the above?
--
David Blevins
310-633-3852
The last
topic we were on in today’s TCK process call was the
issue of what steps needed to be followed in order to be
able to claim compatibility.
- A
Product will be deemed to be “compatible” with the
Specification if it fully and completely meets and
satisfies all requirements of the TCK.
- Before
any claim of compatibility (or any similar claim
suggesting compatibility) is made based on the
TCK, the testing party must:
- use
the TCK to demonstrate that the Product fully
and completely meets and satisfies all
requirements of the TCK;
- make
TCK test results showing full and complete
satisfaction of all requirements of the TCK
publicly available on the testing party’s
website and send a link to such test results
to Eclipse at tck@xxxxxxxxxxx; and
- comply
with any requirements stated in the
Specification with regard to subsetting,
supersetting, modifying or extending the
Specification in any Product claimed to be
compatible with the Specification.
In the current TCK process draft we are
stating that one needs to make a certification request
that requires a number of items, one of which is a
link to the test results. After a certification
request is approved by the corresponding specification
project, it is stated that one email the tck@xxxxxxxxxxx list with
the certification request issue, which would
transitively include the TCK test results.
The point of contention was the order in
which things had to happen. Some were arguing that we
have no ability to avoid a testing party sending their
results to tck@xxxxxxxxxxx and then
being able to claim compatibility. Others were arguing
that the TCK requirements could be a forcing function
that ensured that there was a certification request
issue opened and approved before one could send a
message to the tck@xxxxxxxxxxx list.
Let’s continue the discussion as we need
to wrap up the TCK process doc.
_______________________________________________
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@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
