| Re: [ee4j-pmc] Mailing List Continuity? |
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
On Tue, Jun 18, 2019 at 6:31 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
_______________________________________________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
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.