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 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.
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.
|
