| Re: [jakartaee-tck-dev] [External] : Re: Seeking clarification to question about Milestone TCK releases |
Scott,
We were unable to reach any conclusions in the Specification committee meeting today. It turns out there is a rather complex list of license documents and processes that need to be examined to make sure that we don't inadvertently impact one or the other.
I believe the conversation consensus was, essentially -- keep doing what we have been doing in previous releases and, common library components are not "special" and should just be published under the project license.
More details:
For binary artifacts in a common library, so long as there are no
specification assertions that are somehow contained within these
components, these artifacts should be published under the project
license (for Jakarta EE TCK project, I think that is dual-license,
EPL and GPL v2+CPE but you are welcome to confirm that). There is
nothing in the process that I am aware of, that prevents
publishing (and subsequently retrieving) these to a Maven
repository.
For the TCKs, the Spec. committee would recommend following the existing process -- all publications of the TCKs (continuous build, milestone, pre-final, even final) should be made using the project license. The TCK license should only be applied to the proposed final release. The Spec. Committee will track the SHA-SUM of the proposed final TCK. Finally, the Spec. committee will compute a SIG-SUM, only after the specification is accepted final. The project license TCKs may be published to any location that is within the project charter and it is my belief that the complete TCK may be published to a Sonatype Maven repository.
The Spec. committee was unable to reach any conclusion regarding
publication of Final specification TCKs to a public Maven
repository, though there was speculation that there are
specifications that may do this already. I am not aware of any
requirement, nor even any desirability for publishing any TCK that
is not proposed final with a TCK license. Furthermore, the hash
tracking that the specification process provides has no facility
for ensuring that the archive has been obtained from one location
or another so if a final TCK were obtained from maven central,
that TCK would pass via all the HASH checks (There may be a
process requirement about download location and that is one of the
things that needs further research by the Spec. committee).
Additionally, any pre-final TCK release that is promoted to final
(i.e. CI build, Milestone build, whatever, promoted without
rebuilding) will pass the HASH sum checks. Unfortunately, the
process we are under (at least as outlined here) recommend that
only a Proposed Final TCK include the EFTL and this will almost
certainly require the archive be rebuilt on anything published
earlier than a proposed final release.
I realize this may force rerunning tests that have been performed on pre-final releases but, until we are able to work out additional details of the process and license, we cannot make other recommendations.
CI, Milestone Release TCK -- any TCK build that is published for early access and testing
Proposed Final TCK -- TCK that is built with the intent that this
TCK will become a final release. SHA SUMs are used to track these
TCKs in CCRs that are created for the purposes of the release
ballot. Once a ballot has started, a proposed final TCK may not be
altered in any way without invalidating the the current ballot for
that specification. We do not do this but we could designate
Accepted CCRs using TCKs with this SHA SUM as provisional until
the Specification is promoted to final status. So far, this has
not seemed necessary.
Final TCK -- A TCK that has been successfully ratified and is part of a Final Specification. SHA SUM is tracked and a when the ballot is successful, a SIG SUM is computed for this TCK archive. CCRs with matching SHA SUMs are now final complete (if we used the provisional tag, we could remove that, but this is not currently part of the process) -- We generally do not use the SIG SUM but it is available as an additional check, if there ever was any question about a specific TCK. It is my understanding that Final TCK archives must be made available under both the project license (since that is the license the work was performed under) AND the TCK license.
If you could, please reply with some specific problem cases that
you are encountering so that we can be sure that the Spec.
committee properly addresses the problems you are experiencing.
Thank you.
-- Ed
OK. I will raise the question about publishing pre-final TCKs AS WELL AS the question about common binary artifacts.
-- Ed
On 3/20/2024 8:09 AM, Scott Marlow wrote:
On Wed, Mar 20, 2024 at 10:57 AM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
Hi Scott
In the EE Platform meeting yesterday I had thought that the question
being asked was: what license should be applied to pre-final (e.g.
Milestone) releases of TCKs. It has been suggested that there is a
question about how to publish common binary artifacts that each
component TCK test system may need to consume to perform the tests.
It is true that we also want to publish common binary (Platform TCK) artifacts that may be used by each Component TCK system for which we intend to release milestone releases for if allowed to do so.
Could you please clarify -- are you asking about the requirements for
publication of a pre-final TCK, or are you asking about requirements
implied for a set common utility artifacts?
I did mean to ask about publication of a pre-final TCK but good point to ask about requirements for a set of community utility artifacts.
If you could describe the problem or potential problem you have, today,
that would also be helpful.
Today or soon, I planned to complete a milestone release of common (Platform TCK) artifacts that may be used by Component TCK system found in the Platform TCK.
I ask because, I believe that the TCK license just applies to tests. Not
to the machinery used to run those tests. My initial reaction would be
-- common binary artifacts should be licensed under the TCKs 'project
license' only.
+100
If you can, please try to clarify within the next hour since the Spec.
committee begins a 9 AM pacific daylight time (65 minutes from now).
Thanks Ed!
Thanks,
-- Ed
_______________________________________________ jakartaee-tck-dev mailing list jakartaee-tck-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!ACWV5N9M2RV99hQ!ILLbIa8F1tlMLswTNNB5hxBB-pg_ZMNBDjSNzdDXaILO2dabm4KRq-dZGlgjxoGldKKdlEiRgWVAa4hktqsAtv8354M$