+1 on logging an
Issue. Much easier to query and find than the mailing list, and it's
close to the code.
Thanks Kevin!
+1 from me as well on logging an issue.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From:
Ed
Bratt <ed.bratt@xxxxxxxxxx>
To:
JakartaEE
Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>,
Scott Marlow <smarlow@xxxxxxxxxx>
Date:
06/08/2020
13:20
Subject:
[EXTERNAL]
Re: [jakartaee-spec-project-leads] Expectation for community notification
when removing Platform TCK tests...
Sent
by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx
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?
-- Ed
On 6/8/2020 11:05 AM, Scott Marlow wrote:
Hi,
This question came up a few times recently.
When we remove tests from the Jakarta EE 9 Platform TCK for Specifications/technologies
that are not to be pruned/removed in EE 9, whom should we notify?
1. Ping the respective project
leads via github on the pull request?
2. Or send email to the respective
project mailing list?
3. Or send email to the project
leads mailing list?
Mostly, I would like to know if #1 or
#3 is enough or if the various specification projects would prefer
#2 (so that the entire relevant specification team gets the notification).
Thanks for the input/opinions on what
would work best.
Scott
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads