[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec.committee] TCK documentation requirements
|
One complication, related to TCKs is that a whole boat-load of TCKs are
currently embedded in jakartaee-tck repository. A smaller set of TCKs
are separated out. We intend to separate them all out, but for now the
mapping between Spec., API, and TCK is fairly scattered and inconsistent.
I think that test challenges, ultimately should get to the Spec. team,
but some may initiate as bugs against the TCK, then, after some
analysis, a determination is made that it's really a test challenge, not
just a TCK bug.
Currently, I believe we are heading toward a common Eclipse Project for
these three specification components, but separate repositories for each
of them (Spec, TCK, and API). In that case, the idea about where to file
issues might be somewhat ambiguous. We could disable issues for one or
two of the three repositories in cases like this -- and leave some kind
of notation in the repository about where to file issues. I suspect
there's no one answer that works for all cases.
Anyway, in the process documents, some vagueness is probably good. In
the TCK documents, we probably want to be as specific as we can be.
The current construction of the jakartaee-tck repository documents, does
not currently mirror what is collected into each TCK zip bundle. Build
scripts render, then pull the various material elements into each
bundle. This will likely be something a refactoring effort will correct.
But for now it isn't likely that having documents that would be rendered
nicely when browsing a GitHub repository, will be of much use -- at
least not for the TCK documents that are in the jakartaee-tck repository
right now. The original idea was that this would be material that a user
would unpack at their site so using plain text or html seemed best.
Markdown formmats are becoming more universal, but it aren't as
universal as html.
-- Ed
On 7/25/2019 2:48 PM, Bill Shannon wrote:
I have some questions based on our TCK Process document.
https://docs.google.com/document/d/1Et3LtK-2SUuAoOV56t8R8fKnRWhbWqg9SLgm-VhbDPY/edit
I'd like to resolve these issues in tomorrow's meeting, if not before.
Our TCK Process document says that the TCK UG MUST contain:
- Where to file challenges and bug reports
The TCK UG template currently says:
Challenges should be filed via the {TechnologyFullName} specification
project???s issue tracker ...
It seems that we've been inconsistent on which issue tracker to use for what.
Do we really want certification requests filed against the TCK issue tracker
but challenges filed against the specification issue tracker?
Do we need to add an exact URL to the issue tracker, or is the above sufficient?
Also, the TCK UG doesn't say anything specific about where to file bug reports.
I would hope that it's obvious that bug reports against the TCK should be filed
in the TCK issue tracker. Can we amend the TCK Process document requirement
to remove "and bug reports"?
The TCK Process document also requires that the TCK UG contain:
- A statement that the Certification of Compatibility process must be followed
before a claim of compatibility can be made.
There's currently nothing of this sort in the TCK UG. I'd like to believe this
is clear in the EFTL, which says:
4. Before any claim of compatibility (or any similar claim suggesting
compatibility) is made based on the TCK, the testing party must:
a. use the TCK to demonstrate that the Product fully and
completely meets and satisfies all requirements of the TCK;
b. 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](mailto:tck@xxxxxxxxxxx); and
c. 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.
Can we remove the above requirement from the TCK Process document and rely
on the EFTL?
Finally, the TCK Process document requires:
- A top-level README.md document pointing to each of the preceding documents.
Currently many, but not all, TCKs include a README.html that links to the
other documents.
Can we change the TCK Process document to *not* require a markdown file?
Do we need to add README files of some sort to all the TCKs?
_______________________________________________
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