| Re: [cu-dev] TCK Service release |
|
Steve, Did you mean to include a list of the challenges? The following query shows 5 outstanding issues labeled with challenge, https://github.com/jakartaee/concurrency/labels/challenge 4 of them have been around for over a month, 3 of which would qualify for being accepted with lazy consensus and if my reading of the
TCK challenge process is correct, either also falls under lazy consensus – which does not mean unanimity – or otherwise under “If consensus cannot be reached by the specification project
for a prolonged period of time, the default recommendation is to exclude the tests and address the dispute in a future revision of the specification.” The fifth one was just opened by Arjan due to an erroneous difference between the TCK zip and the TCK jars on maven, the former accidentally lacking a final pull that was merged the same day per other conversation, https://github.com/jakartaee/concurrency/issues/239 Hopefully we can just quickly vote to accept this last one rather than waiting for a couple of weeks for lazy consensus. From:
cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> All, In order to get to a service release of the TCK we need to accept the following challenges. Is the team ready to accept these challenges? According to the
TCK process we are only supposed to exclude the tests from the service release of
ZjQcmQRYFpfptBannerStart
ZjQcmQRYFpfptBannerEnd All, In order to get to a service release of the TCK we need to accept the following challenges. Is the team ready to accept these challenges?
According to the TCK process we are only supposed to exclude the tests from the service release of the TCK not “fix” them. I suggest we merge in the fixes (so as not to lose them) and then exclude the tests. Is everybody happy with that? Thanks Steve Millidge |