| [jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - November 16th, 2022 |
Attendees (present in bold):
Kenji Kazumura - Fujitsu
Tom Watson - IBM - Emily Jiang
Ed Bratt - Oracle - Dmitry Kornilov
Andrew Pielage - Payara - Petr Aubrecht
David Blevins - Tomitribe - Jean-Louis Monteiro, Cesar Hernandez
Ivar Grimstad - PMC Representative
Marcelo Ancelmo - Participant Member - Martijn Verburg
Werner Keil - Committer Member
Scott Stark - Red Hat - Scott Marlow Enterprise Member
Zhai Luchao - Shandong Cvicse Middleware Co. - Enterprise Member
Eclipse Foundation: Tanja Obradovic, Paul Buck (chair)
Past business / action items:
Approval is requested for the meeting minutes from the November 2nd, 2022 meeting as drafted - Approved.
Agenda:
Ongoing tracking spreadsheet of individual specs progressing through the JESP
Inprogress - https://jakarta.ee/about/jesp/ being updated and Paul to send email to discussion mailing list to communicate the availability of JESP 1.4
PR 1517 was merged, email to be sent to notify projects/leads and via the appropriate mailing lists [Scott S.]
Approval of Jakarta Security Restructuring [Scott]
Merge the 3 security specification projects into one, see issue #392
Specification Committee was asked if there were any objections to proceed w/ the merge as documented in issue #392
No objections were raised, this request is approved
Work on and resolve Specification Committee’s process enhancements items including those identified in the Jakarta EE 10 retrospective:
Issues with the “enhancement” tag https://github.com/jakartaee/specification-committee/issues
Enhancment issues in a project board https://github.com/orgs/jakartaee/projects/1/views/1
Does the EFSP mandate that authoritative sources live within a specification project? That is source input that ends up producing the final specification content [Tom]
Concerned about the situation w/ MyFaces https://github.com/jakartaee/faces/blob/354746532d8a325f7114c53ff33ce880aeaa4243/api/pom.xml#L313-L350
API JAR’s are provided as a convenience, they are not normative. The JavaDoc and signature tests are part of the spec and therefore normative.
Is it a requirement that the sources used to create normative artifacts required to be managed as part of the specification project’s sources?
Is there a situation where a committer may have merged an artifact from sources outside of the project that has provenance elsewhere?
Is there a situation where there is a committer on an open source project that is not a committer on the specification project, where that committer has contributed to an artifact that is normative?
Need to establish policy (if required) that apply to all specs
Proposal - Invite Wayne Beaton to the next meeting (30th) to explore this topic further.