|
CI == Compatible Implementation -- this would be the something
that can execute the API itself, an application server, or
anything that implements the specification. The TCK needs an
implementation to run against. I many (but not all) component
cases that Oracle has contributed, the component tests are run
from a test implementation of Eclipse GlassFish. In most of these
cases, GlassFish is just a "well known archive" which contains all
the necessary components.
I think you are suggesting that the "default" action will be: if
the project contains both an implementation and an API, it will be
converted to a Specification project. Have I got that right? So,
in my example, below for _expression_ Language -- we would just add
the meta data for Specification Project, leaving the rest
unchanged?
Cheer,
-- Ed
On 6/18/2019 7:34 PM, Wayne Beaton
wrote:
The immediate goal is no reorganization, with some
exceptions. We're going to, for example, split a new Jakarta
Server Faces project off of Eclipse Mojarra. At least initially,
Jakarta Server Faces will be the home for the specification
document only. We should end up with more-or-less the same
number of Eclipse projects that we have now.
For most projects, we're going to morph the existing
project into a specification project. The PMC has
recommended that we use existing "API" Git repositories as
homes for specification documents.
Based on what was discussed by the steering committee
today, my understanding is that we no longer need to
change project ids or short names and, by extension,
project URLs, GitHub repository names, and mailing lists.
So, unless I'm told otherwise, I have no plans to change
any of those things as part of the restructuring reviews
that we're doing to turn our existing projects into
specification projects. If project teams want to change
their short name, repository name, etc. they can work with
EMO and/or Webmaster to make those things happen.
Every Eclipse project (including specification projects)
has a team of committers (which manifests as a single GitHub
Team) and zero or more GitHub repositories. The team of
committers has uniform access across all repositories
aligned with the project.
I assume that by "CI", you mean "TCK". We're not
restructuring repository ownership. Those projects that
currently have a TCK repository will keep their TCK
repository.
I believe that Kevin's characterization of what happens
when mailing lists are moved is accurate.
HTH,
Wayne
Kevin, It would be great to hear that confirmed by a
webmaster for Eclipse (or whomever is actually going to be
doing this work). For example, if one is subscribed to:
_expression_ Language -- right now, both the Compatible
Implementation (CI) and the API binaries are produced out
of a single repository. Messages on e-mail and repository
notifications regarding either the CI, the Spec, or the
API all go on el-dev@xxxxxxxxxxx or emanate
from the github repository at github.com/eclipse-ee4j/el-ri
If the immediate goal is -- no reorganization
immediately, just a few name changes here and there,
perhaps these are questions for another day and you can
just stop reading right now.
If that's not the immediate goal, after the split, do we
intend to have two projects: one for the CI and one for
the API? Regardless, I would presume we will have two
repositories (one for the CI and one for the api). Will
the same GitHub "Team" be used for both? Maybe it would be
best to "clone" the team so that they could eventually
diverge? It is entirely plausible a new repository could
be created for the API -- and it might only contain the
Specification document immediately. If that's the case --
I think these questions would still apply (same or
different project? same or different team? ...)
Sorry, there are just lots of details. It would be great
if the plan to implement this were visible so that we
could review and assure ourselves that questions like this
are answered.
-- Ed
On
6/18/2019 1:25 PM, Kevin Sutter wrote:
When we
had to modify some of our mailing list names in the
early days of EE4j/Jakarta, the move was transparent to
the subscribers. Everything just got moved
automatically. But, if I remember right, the history of
the previous mailing list didn't transfer. If you
wanted to view the history of the previous mailing list,
you had to look at that one specifically. I think...
Someone from the EF would know for sure.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta 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:
Ed Bratt <ed.bratt@xxxxxxxxxx>
To:
ee4j-pmc
PMC List <ee4j-pmc@xxxxxxxxxxx>
Date:
06/17/2019
10:43 AM
Subject:
[EXTERNAL]
[ee4j-pmc] Mailing List Continuity?
Sent
by: ee4j-pmc-bounces@xxxxxxxxxxx
Hi,
Given the project / repository restructuring across
EE4J sub-projects,
will committers need to watch for and resubscribe to
mailing lists, or
will subscriptions be migrated across project (and
presumably
mailing-list) name changes (for the cases where the
community team
elects to make a change)?
-- Ed
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
|
