Yes, it's a pity indeed I didn't notice it either, but things happen. I'll rebuild the zip, double check it, and re-run the TCKs and such. It's by itself not that difficult to redo.
I don't consider myself more knowledgeable, but since there
doesn't appear to be anything more than the readme.md file
containing run and usage requirements, I would recommend we
withdraw this ballot, repackage the TCK correctly and re-run the
ballot. This will, regretfully require the CCR tests be rerun with
the updated TCK, and the TCK Summary (and CCR) updated to
reference the revised SHA sum.
The TCK user guide does contain information important to
achieving compatibility so it's important that this document be
included. I think the general case is that both an HTML and PDF
copy are included in the zip-file.
It is too bad the mentor didn't discover this prior to bringing
it to ballot but we were all working to meet the deadline. I think
we can run this ballot again without losing our June end-date. (If
we respin and restart it this week, it will conclude by June 3.) I
wouldn't expect anyone's ballot vote to change so I don't see this
as a risk.
That's my preference. I'm open to other suggestions.
Cheers,
-- Ed
On 5/17/2022 6:31 AM, Andrew Pielage
wrote:
As
commented on the PR itself, the staged TCK is missing the
TCK User Guide.
Arjan
asked if we’re allowed to update the TCK mid-ballot, and I’m
not confident on saying whether we are or not?
It’s
a non-functional change in the same manner as a copyright
license update, but it’s on the TCK so updating it would
presumably change the SHA and arguably justify needing the
CI in the CCR to be rerun against it?
If
someone more knowledgeable can advise it would be
appreciated, although I think I’m the only person to have
not voted +1 so far so unless this invalidates the ballot I
think the die is cast.
Apologies
for noticing this at the 11th hour!
Thanks,
Andrew Pielage
Java
Developer at Payara Services Ltd Payara Services Ltd - Open Source Enterprise
Software & Support
I request your vote to approve and ratify the release
of Jakarta Security 3.0 as part of the Jakarta
EE Platform 10 release.
The JESP/EFSP requires a successful ballot of the
Specification Committee in order to ratify the
products of this release as a Final Specification (as
that term is defined in the EFSP).
Per the process, this will be a fourteen-day ballot,
ending on May 17, 2022, that requires a
Super-majority positive vote of the Specification
Committee members (note that there is no veto).
Community input is welcome, but only votes cast by
Specification Committee Representatives will be
counted.
The Specification Committee is composed of
representatives of the Jakarta EE Working Group Member
Companies (Fujitsu, IBM, Oracle, Payara, Tomitribe,
Primeton, and Shandong Cvicse Middleware Co.), along
with individuals who represent the EE4J PMC,
Participant Members, and Committer Members.
Specification Committee representatives, your vote is
hereby requested. Please respond with +1 (positive), 0
(abstain), or -1 (reject). Any feedback that you can
provide to support your vote will be appreciated.