Re: [jakarta.ee-spec.committee] [External] : General questions -- regard

[Ed Bratt <ed.bratt@xxxxxxxxxx>]

For what it's worth, the check-boxes near the bottom of the Spec. finalization check-list regarding EMO related tasks are tracked in the EMO release tracking issue that is created when the project committer team (lead) notifies the EMO that the release is imminent.

For this release, I would recommend that each of us mentors ask the project team/lead for the issue ID that the EMO created, so that it's easy to track that these check-list items have been completed.

As an example, in SOAP with Attachments, the EMO tracking issue is here. In that issue are links and check-list boxes for each of the check-list items from the mentor checklist.

In the future, I'd recommend we update the initial PR template check-list and ask the PR submitter to record the EMO issue link. Then, these mentor-check-list items will be easy to confirm.

Here are the check-list items from the spec. finalization check-list (the three indented check-boxes may be verified from the EMO issue) that I'm writing about.

In the initial PR template, the check-list item only asks the submitter to verify that they have initiated started or carried out these process items. We could add a request to capture the link for the EMO issue (then, us mentor's only need to verify that the boxes are checked in the EMO issue)

Add at the end of this indented list: please add a link to the GitLab issue the EMO creates in response to your e-mail to start a release review. With that, we will have everything we need to complete those check-boxes.

Thanks,

-- Ed

On 2/11/2022 5:05 PM, Ed Bratt wrote:

> These
>       came up while I was reviewing Jakarta EE Concurrency with the
>       latest mentor checklist. I'm posing the questions here on the
>       chance that someone's already encountered these and/or has an
>       answer for the rest of us to follow: 
>       
>       TCK Format and content: I don't think we ever settled on the
>       question of what to allow for final TCK that can be published
>       through Maven Central. This was discussed over e-mail in early
>       December and it's been carried on the Spec. committee as a "to do"
>       item under the heading of "TCK Archive format." It's time for us
>       to reach a conclusion on this topic. We need to settle on the
>       final package format and a suitable manifest/BOM so that we can
>       properly advise the Spec. development teams properly. (I'll send a
>       reply to this thread to bump it, in case you use "threaded" view
>       in your e-mail client.) 
>       
>       TCK SHA sum: In the past, we used SHA-256 for TCK. Do we want to
>       allow Spec. teams to simply refer to the SHA1 hash that is
>       produced when the artifacts are uploaded to Maven? Otherwise, we
>       will need teams to continue to manually generate the SHA-256 and
>       include the SHA in the ancillary material (the PR, the CCR, etc.)
>       
>       
>       License for TCKs -- I believe the TCK license must be the Eclipse
>       TCK License. For publication at Maven, we allow the TCK to be dual
>       licensed -- and add EPL (EPL allows it to be pushed to Maven.
>       Users who submit CCRs agree to the terms of the TCK License. Is it
>       acceptable for the Spec. teams to just merge these two licenses
>       together? (Me? I'd recommend we provide a reference license that
>       we know is "blessed".) 
>       
>       At what point is the EMO contacted? Once the Spec. checklist is
>       completed? Or, does the Spec. dev. team initiate that whenever it
>       is ready? 
>       
>       Checklist item "no other files" 
>       
>       Based on previous problems I think that we have concluded its best
>       not to force the HTML Spec. copies to embed all images. Therefore,
>       is it true that we do not require embedded images in HTML
>       documents (i.e. it's okay to have an images folder that contains
>       images in the HTML). Correct? Do we need/want to settle on the
>       naming convention so that the HTML pages can be easily copied, or
>       do we just leave that to the discretion of the development teams?
>       
>       
>       _______________________________________________ 
>       jakarta.ee-spec.committee mailing list 
>       jakarta.ee-spec.committee@xxxxxxxxxxx 
>       To unsubscribe from this list, visit
> https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee__;!!ACWV5N9M2RV99hQ!eZ7CWhYCkrWPQwUEUCfUx8F-DXCU4jkqYWtsKqQe-4MVK0cWLBJPO7fFuhFkHzU$
>