I need help with some of the comments that have been raised (mostly around license issues) in the release review issue under https://github.com/jakartaee/specifications/pull/449
“The TCK must be licensed under the EFTL. For distribution via Maven, the TCK may be dual licensed: EFTL + EPL. Please revise the tom-level license docs and discard the EPL + GPL v2 license docs. Source-code license headers need not be
updated.”
Could someone who knows what they are doing with licenses correct the above? Does this require re-building the candidate final copy of the TCK? If so, this will push us out a month (if we can get everything corrected and rebuilt within a week) and otherwise
longer because our candidate compatible implementation will need to publish another beta upon which we can run any updated TCK.
“I will need to get clarification from the Spec. committee about the final distribution of the TCK materials. Current check-list requirement is that we provide the TCK as a complete bundle .zip file that is linked to the controlled Specifications download folder.
For CU 3.0, this would be: download.eclipse.org/jakartaee/concurrency/3.0/jakarta-concurrency-tck-3.0.0.zip -- You can use the
CU 2.0 archive to review the contents if that is helpful. Also please review the Mentor Checklist items 6, 7, and 8 for additional details.”
If I understood the above correctly, it sounds like splitting the TCK out of platform and building it in our main project might not fit with some of the rules, although I know several other specifications are doing the same. Our TCK is a JAR file suitable
for publishing to Maven, not a ZIP,
https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-tck/3.0.0/
Hopefully, Ed will be able to get clarification allowing us to continue using this approach, and that would seem to cover most of the troubles with getting sections 6, 7, and 8 checked off, but I also see a checkbox asking for a “EFTL license file, preferably
named LICENSE.md” which we don’t have in our TCK, which goes back to the first issue mentioned.
“I do see that there is a docs folder in the Maven source archive. This only includes the license file. Lacking further documentation, I would recommend this release use the previously created cu 2.0 TCK zip as the proposed list of contents -- if anything is
to be discarded, we can explicitly decide to remove it.”
I don’t understand the above. Hopefully, someone else does.
“The Java doc link to the Spec. License HTML file yields 404 in the Netlify preview. Please correct if needed.”
I tracked down the above to
https://deploy-preview-449--jakartaee-specifications.netlify.app/specifications/concurrency/3.0/apidocs/
which has some fine print at the bottom of the page with a copyright “license terms” broken link to
https://deploy-preview-449--jakartaee-specifications.netlify.app/specifications/concurrency/3.0/apidocs/doc-files/speclicense.html
Sure enough, our generated 3.0 javadoc jar file,
https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-api/3.0.0/jakarta.enterprise.concurrent-api-3.0.0-javadoc.jar
doesn’t have any doc-files/speclicense.html
unlike the 2.0 javadoc jar file, which does have it,
https://repo1.maven.org/maven2/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-api/2.0.0/jakarta.enterprise.concurrent-api-2.0.0-javadoc.jar
What changed here that got rid of this and how to correct it? I assume this will require re-building everything (once a fix is made) rather than just grabbing the copy from the 2.0 jar and checking that in.
Would someone else be willing to take over at this point sorting out the process stuff? This is an area that I do poorly with and I’m not even the lead for this spec.
From:
"Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: Wednesday, February 9, 2022 at 9:12 AM
To: Nathan Rauh <nathan.rauh@xxxxxxxxxx>, cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>, Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: [EXTERNAL] RE: Release process for Concurrency 3.0 spec
Hi Nathan,
As you are a committer I think you can do those things which is why you get can get so far. I don’t remember a lot of the process. I see you have added Ed/Dmitry I think they are our mentors available to us to help guide
us through this part of the process.
Steve
From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 08 February 2022 17:44
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>; Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>; Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: Release process for Concurrency 3.0 spec
Given that we’re supplying the candidate for compatible implementation and have the information for it and the results and so forth, I’ve been trying to fill out some of the process for the 3.0 release based on
this, and I’ve been surprised how far it seems to be letting me go without any additional authorization. Thus far I have the following two issues mostly filled out (some links within the checklists won’t be working until a week from now) and it even allowed
me to update the release record to replace the projected release date of last October with Feb 28 and to request a Generated IP Log, although I have no idea if I’ve done those things properly or if I should have included more information. To any of you who
know what you are doing with this sort of process, please review and correct or fill in parts that I have missed. I’m hoping that we will be able to check off the remaining boxes and submit the release review a week from now. If anyone else would like to
take over, I’d be happy to let them.
Concurrency 3.0 release review issue:
https://github.com/jakartaee/specifications/pull/449
Concurrency 3.0 compatibility certification request issue:
https://github.com/eclipse-ee4j/jakartaee-platform/issues/464
