Scott,
In general, it depends on where the source of compatibility
requirement originates. If it comes from a component
specification, that API committer team should approve that the
test is no longer required. If in doubt, I would recommend asking
the Jakarta EE Platform committer team.
At the release, each component API committer team is responsible
for their specification, their TCK, their API, their API Docs, and
representing that a compatible implementation passes that TCK. The
same is true for Jakarta EE Platform, but the scope there can be
broader. In each case, we should presume that there was something
in the Spec. that caused the compatibility test case to be
generated, therefore, that initial assertion, should be reviewed
(maybe it will need to be changed, maybe not). I realize that this
won't always be a clear association.
My personal choice would be to file an issue with the API
repository that you think is impacted. That API team should
provide resolution via some overt action on that issue. That way,
there's a trail that can be tracked, even if someone isn't
subscribed at the time. If the issue requires a PR to implement a
change in a repository, that can also be used, per the normal
process, but sometimes the PRs will not in the same repository
(i.e. if the TCK uses a separate repository).
Is this helpful?