Not today but I saw it before, sure you got the Right link? Sent from Mail for Windows 10 Anyone else having problems logging in to zoom? I get the message that the host is busy with another meeting..... Roles of the PMC and Specification Committee:
PMC manages the governance process, and provides oversight. They ensure that the open source rules of engage are observed and the EDP as a whole is followed. They participate in the Intellectual Property process to ensure that requests for review are technically sound (e.g. ensure that the use of third party content makes technical sense). They provide best practices. The PMC owns the software "stack" (i.e. their view spans the concerns of all subprojects). The PMC tends to work more at the development/technical level.
Specification Committee owns the overall vision of how all the different specifications fit together. <strike>They provide a channel for intellectual property flows (I may not be expressing this correctly).</strike> The Specification Committee provides oversight for the implementation of the EFSP and certification process on behalf of the Working Group, owns the process of promoting and maintaining Final Specifications
Approvals from both parties are required for lifecycle Reviews.
The PMC is in the Project Leadership Chain; the Specification Committee is not.
The term "profile" is a flag for marking specifications that extend branding privileges to Compatible Implementations. Further, we apply special voting requirements to profiles, so we need a definition. Do we need the term "platform" to be formally specified as part of the process? What is special about platforms (with respect to the process)? Is the use of this terminology sufficient? "Compatible Implementation: is any implementation that fulfills all requirements of a Specification Version as demonstrated by fulfilling all requirements of the TCK."
Are these statements sufficient? A Compatible Implementation must fully implement all non-optional elements of a Specification Version, must not not extend the API (no supersetting), and must fulfill all requirements of the corresponding TCK.
Is it sufficient to require that just one Compatible Implement fully implement a specification, including all optional elements? A Specification Version must identify at least one Compatible Implementation under an Open Source License that implements all optional elements of the Specification and fulfills the requirements of all elements (including optional elements) of the TCK.
By way of clarification, when we say that a CI must implement all optional elements, does this apply to the prerequisites? e.g. (hypothetical) if one has to implement all optional elements of the JSP specification; does one have to also implement all optional elements of the servlet specification, or only those optional elements of the servlet specification that the JSP specification requires be implemented? The answer to this question, should be an FAQ entry. Do we need to make it clear that adding a Compatible Implementation to a Final Specification does not change the Final Specification? i.e. no ceremony is required. IMHO, the process by which Compatible Implementations get added is an implementation detail. -- Wayne Beaton Director of Open Source Projects | Eclipse Foundation, Inc. Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25 
This e-mail and any attached files are only for the use of its intended recipient(s). Its contents are confidential and may be privileged. Fujitsu does not guarantee that this e-mail has not been intercepted and amended or that it is virus free. If you have received this e-mail and are not the intended recipient, please contact the sender by e-mail and destroy all copies of this e-mail and any attachments. / Le présent courriel, ainsi que ses pièces jointes, ne peut être utilisé que par le ou les destinataires auxquels il a été transmis. Les renseignements qu'il contient sont confidentiels, voire même protégés. Fujitsu ne peut garantir que ce courriel n'a pas été intercepté ou modifié, ou qu'il ne contient aucun virus. Si vous avez reçu ce courriel sans en être le destinataire prévu, veuillez communiquer par courriel avec son expéditeur et en détruire toutes les copies et pièces jointes. _______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
-- Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader |
