Scott Kurz wrote on 7/31/19 6:45 AM:
I think we should have consistency in where to
host the certification issues.
Reading: https://docs.google.com/document/d/1Et3LtK-2SUuAoOV56t8R8fKnRWhbWqg9SLgm-VhbDPY/edit#heading=h.c86x9rk7bay9
FYI, that document is obsolete. The current version
is here.
Yes, bad on us for not communicating this clearly. :-(
Requests to be acknowledged as a
certified implementation MUST be filed via the specification
project’s TCK issue
tracker using the
label `certification` and include the following information:
I see I'm the only one who interpreted that as an
issue against the TCK project. The other examples use spec
project issues, not what I assumed was the intent in saying
"TCK issue tracker".
We changed this recently.
So if we agree it's the spec project that should
host these issues, I can go (re)create all the required labels
for the TCK challenge workflow over in the batch-api (spec)
project to support this.
Hopefully the doc can be updated to clarify (and
maybe also add the comment: - "The
TCK results should be hosted by the Compatible Implementation
not by the Specification Project").
If that's not clear in the latest documents, please
suggest where we should add it, or submit a pull request against
the documents.
---
The wording comes up again related to
"Improvement" - Requests for
improvement to tests MUST simply be created as issues with a
label of `enhancement` in the specification project’s TCK issue
tracker.
IMHO, I do think it might not be helpful at this
point to try to specify an "enhancement"-related workflow.
Enhancements may be added for a variety of overlapping
reasons: new features, increased coverage of old features,
better automation, maybe even refactoring, and we're going to
end up with some diverse approaches I'd think.
Bugs and enhancement requests against the TCK itself
should be filed in the usual manner against the TCK project. We
may be over-specifying that here.
|
