| Re: [jakarta.ee-spec.committee] Specification Committee call agenda, October 3/2018 |
_______________________________________________On 2018-10-04 9:48 AM, Kevin Sutter wrote:
I agree, Bill, that we haven't defined who owns the overall architecture of Jakarta EE. I think we determined yesterday that the Spec Committee does not own this architecture. From past conversations, I think we have also agreed that it's not the EE4J PMC. So, is it the Platform project? This might be the logical choice, but we haven't defined that role yet. We need to put this definition and anointing on our list of things to do...
I distinctly remember a conversation some months back where this was suggested. E.g. that the architecture role should be played by the Jakarta EE Platform Specification Team.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Bill Shannon <bill.shannon@xxxxxxxxxx>
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date: 10/03/2018 06:23 PM
Subject: Re: [jakarta.ee-spec.committee] Specification Committee call agenda, October 3/2018
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Wayne Beaton wrote on 10/ 3/18 07:51 AM:
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.
As discussed in today's meeting, the problem with the above is that it seems like both the PMC and the Spec Committee are providing "architecture" and/or "vision" for the projects.
Somebody has to define the architecture and somebody has to check that the result fits with the architecture. I expected that the Spec Committee, like the JCP EC, was doing the latter. I'm not sure whether it's the PMC or the "platform project" that does the former.
There's a theoretical problem here if one group defines the architecture and another group gets to say "I don't approve what you've done because I disagree with the architecture". I think we solve that in practice by having many of the same individuals/companies involved in both the creation and the approval.
I'd love it if the FAQ included examples of the kinds of activities or decisions that the PMC and the Spec Committee engage in, something more concrete than "oversight" and "ensure the EDP is followed".
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)?
I'm fine with keeping it in the process document but not saying much about it.
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?
Yes.
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?
Yes.
(Fix "not not" above.)
A Specification Version must identify at least oneCompatible 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.
Depends on the requirements of the JSP specification. If the JSP specification doesn't depend on some optional elements of the Servlet specification, the full JSP CI wouldn't need to implement those optional elements of the Servlet specification. In general, a JSP CI wouldn't be implementing the Servlet spec at all, but would require a Servlet CI to run on.
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.
What does it mean to "add" a Compatible Implementation to a Final Specification?
As I've said previously, the specification document should not refer to any implementations. The Project Review should include information about Compatible Implementations. Once the review is complete, there's no need to update that information, but we might want to separately maintain a list of Compatible Implementations for a given spec.
_______________________________________________
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
_______________________________________________ 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
--
Mike Milinkovich
Executive Director | Eclipse Foundation, Inc.
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
@mmilinkov
+1.613.220.3223 (m)
Meet us at EclipseCon Europe 2018: Germany, October 23 - 25
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
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.