|
Hi Ivar,
here is the link
https://eclipse.zoom.us/j/355402799
Tanja
On 2018-10-03 12:11 PM, Ivar Grimstad
wrote:
Using the calendar invite from the Spec committee
calendar, so I assume it is the correct one...
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.
--
Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader
_______________________________________________
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
_______________________________________________
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
--
Tanja Obradovic
Jakarta EE Program Manager | Eclipse Foundation, Inc.
Twitter: @TanjaEclipse
Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25
![Avast logo]()
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
|
