Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakarta.ee-spec.committee] Fwd: [jakarta.ee-steering] [External] : Re: Migration/Separation of Specification projects to different GHO
I was asked to forward this to the Spec. committee list - I realize many of you are already on that list, but not everyone. This was discussed at Steering Committee yesterday. I believe there was no conclusion from our conversation at the Steering Committee but there was some general notion that the Spec. committee might be interested in weighing in on this and perhaps making a recommendation -- if one is to be made.
Short summary -- we are in the midst of migrating Specs out of eclipse-ee4j Github organization into jakartaee GitHub organization. I thought one goal of this was to improve the organization. After seeing the results of a few specifications organically migrating their repositories, I am concerned that we are just moving our disorganization from one GHO to another and ... I guess I had hoped things would be more improved.
I am including the original message and all replies as attachments. I hope our mail clients present them in a coherent fashion. 

I apologize for the URL Defense links.

-- Ed
--- Begin Message ---
  • From: Ed Bratt <ed.bratt@xxxxxxxxxx>
  • Date: Mon, 10 Jan 2022 11:20:58 -0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6Qohj7wadaOKmvrwFrD/spgiazxdjQ46rdprEhAeRaA=; b=h71nYAkqI3mb990htQsSTH8/GA+KLyKJALi52X2BMsmxU16Wv60NMnEdNbJvZmxBiXcoAK7ZahCRIL3UjlQNc5FU2rTki4kPxxj/AWdaXJnRJ0SD2/ZCrde4y0LnhfBefw7V1hb3Q7OHRPjnZNrv4Z5FlAVWWis64kf4lvGA1C8upXTcpWSpwaXF6v1soZCjfvE+t6tzVK/APBAuGDuXjeHIruGlO/lnk0iiksnts7bln1dAF1rvEaMKzH+e8760u8I73+pJqHxJWP5I4Qf7tGlskpRnQaq6vdnwK7A5vjtfs9kw+ShPpKfFZ8i9zBuqh8vu44uzbDrKBS8bLN3hBg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZQH6sh5bClF7N++aXi9gjJJCHkALRANkAx2Q3bqftJfi+ZmsePac3VZuEOss7AMT/V8Ek+1v7Ju2ME3fEh9IJuv9WOX8gFEvg1b/pO8qYvTNjm0rEMxWsWH1IIato8GI/1SmvBRPrXCeCmIFQjWoR2ebWx21TYaZ0SbJE/62jRjPZPD4m1UQhPBPxuZ5j2NV0cl37wi2HCHQAQznfYHIXZO3QFuvBSU6CNqM6Ac28LLooqdmDKrXb+/n3KVv6ThdNNXLSzsSq5GNO70idTgAzl6eSZi4qTDmMGkdauJfUdMTDmla18OheRznrW2DQ3zjS21gEHBc3ql6ga6Ln2qOrw==
  • Delivered-to: jakarta.ee-steering@xxxxxxxxxxx
  • List-help: <mailto:jakarta.ee-steering-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering>, <mailto:jakarta.ee-steering-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/jakarta.ee-steering>, <mailto:jakarta.ee-steering-request@eclipse.org?subject=unsubscribe>
  • User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1

Hi,

In 2019 the steering committee passed a resolution to separate Specification projects from Implementation projects. David had provided the following history:

- Proposal: https://docs.google.com/document/d/1vQst9k0fOGhUbbw3RoOvi-BvjiSsADH4dyjqTquIwE8/edit?usp=sharing
- Approval: https://jakarta.ee/about/meeting_minutes/steering_committee/minutes-june-11-2019.pdf
- Breakdown: https://docs.google.com/spreadsheets/d/1uoCebbw2ucpFO389VwTIEd6cqwBXhgE3Cq2fhS6g6ps/edit?usp=sharing
- Prototype: https://github.com/orgs/jakarta-ee

Reviewing the proposal outline above, and comparing it to what is happening I am noticing that

  1. we aren't following the prototype and
  2. the results, as they are moving forward, at least to my eye, are confusing

Is this what the committee was expecting? Do we want to make changes to what has already happened?

Details:

Some Specs. are being migrated out of the Eclipse-EE4J github organization. They appear to be migrated into the existing jakartaee GitHub organization (the hyphen between jakarta and ee has been dropped) instead of github.com/jakarta-ee, they are going into the existing github.com/jakartaee organization.

When I look in the jakartaee Github organization, I'm noticing that it seems a bit confusing in that -- there are repositories that hold normative data (i.e. jakartaee/specifications) some that hold web-site data (e.g. jakarta.ee, jakartaone.org. jakartablogs.ee) and then the specification specific working repositories themselves (e.g. messaging, messaging-proposals, security, etc.).

I wasn't expecting this mixture of differing types of repositories. I think I'd imagined that there would be a separate specification specific organization and all the spec. working repositories would be in that. Then, a separate organization would hold all the final archives. To my brain, the most jarring thing is there's the jakartaee/specifications repository -- then there are each of the specification repositories (or sets of repositories) -- and this seems confusing to me.

Was this the expected outcome of this reorganization?

Do we anticipate that the TCK and other ancillary repositories will be migrated here too? I ask because I would like to keep the TCKs with the Specifications. If that's the case, then I think we will want to have Jenkins/CI resources available for this aspect of these projects -- so that those projects can consistently test changes to their TCKs. If there is agreement on that aspect, we probably want to make sure that, when a Spec. migrates to the new GitHub organization, it is also provisioned with a CI resource as well.

I'm not sure if this can be resolved in e-mail, or if this needs discussion time at the Steering Committee meeting.

Thanks,

-- Ed

_______________________________________________
jakarta.ee-steering mailing list
jakarta.ee-steering@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering__;!!ACWV5N9M2RV99hQ!Y6gS1NoC84aZjMEspm15SbYlQM1_d2bPjFsUdgCMU4VP-AbHHqJBl8mXw2NefpM$

--- End Message ---
--- Begin Message ---
Hi,

Although this is not something we can solve here, or at all, core of the issue is perhaps the impossibility of github to properly support 2 or more level structures in an org.

github/jakarta-ee vs github/jakartaee doesn't seem any less confusing to me.

We probably either need a structured org organization, kinda like github/eclipse and github/eclipse-ee4j, or a repo organization, which would mean specific prefixes for each repo.

Just a thought, but e.g.

A repo organization could look like:

github/jakartaee/spec-faces
github/jakartaee/spec-pages
github/jakartaee/spec-authorization
...
github/jakartaee/normative-specifications
...
github/jakartaee/website-jakarta.ee
github/jakartaee/website-jakartaone.org
...
etc

A org variant would be:

github/jakartaee-spec/faces
github/jakartaee-spec/pages
github/jakartaee-spec/authorization
...
github/jakartaee-normative/specifications
...
github/jakartaee-website/jakarta.ee
github/jakartaee-website/jakartaone.org

Thoughts?











On Mon, Jan 10, 2022 at 8:21 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:

Hi,

In 2019 the steering committee passed a resolution to separate Specification projects from Implementation projects. David had provided the following history:

- Proposal: https://docs.google.com/document/d/1vQst9k0fOGhUbbw3RoOvi-BvjiSsADH4dyjqTquIwE8/edit?usp=sharing
- Approval: https://jakarta.ee/about/meeting_minutes/steering_committee/minutes-june-11-2019.pdf
- Breakdown: https://docs.google.com/spreadsheets/d/1uoCebbw2ucpFO389VwTIEd6cqwBXhgE3Cq2fhS6g6ps/edit?usp=sharing
- Prototype: https://github.com/orgs/jakarta-ee

Reviewing the proposal outline above, and comparing it to what is happening I am noticing that

  1. we aren't following the prototype and
  2. the results, as they are moving forward, at least to my eye, are confusing

Is this what the committee was expecting? Do we want to make changes to what has already happened?

Details:

Some Specs. are being migrated out of the Eclipse-EE4J github organization. They appear to be migrated into the existing jakartaee GitHub organization (the hyphen between jakarta and ee has been dropped) instead of github.com/jakarta-ee, they are going into the existing github.com/jakartaee organization.

When I look in the jakartaee Github organization, I'm noticing that it seems a bit confusing in that -- there are repositories that hold normative data (i.e. jakartaee/specifications) some that hold web-site data (e.g. jakarta.ee, jakartaone.org. jakartablogs.ee) and then the specification specific working repositories themselves (e.g. messaging, messaging-proposals, security, etc.).

I wasn't expecting this mixture of differing types of repositories. I think I'd imagined that there would be a separate specification specific organization and all the spec. working repositories would be in that. Then, a separate organization would hold all the final archives. To my brain, the most jarring thing is there's the jakartaee/specifications repository -- then there are each of the specification repositories (or sets of repositories) -- and this seems confusing to me.

Was this the expected outcome of this reorganization?

Do we anticipate that the TCK and other ancillary repositories will be migrated here too? I ask because I would like to keep the TCKs with the Specifications. If that's the case, then I think we will want to have Jenkins/CI resources available for this aspect of these projects -- so that those projects can consistently test changes to their TCKs. If there is agreement on that aspect, we probably want to make sure that, when a Spec. migrates to the new GitHub organization, it is also provisioned with a CI resource as well.

I'm not sure if this can be resolved in e-mail, or if this needs discussion time at the Steering Committee meeting.

Thanks,

-- Ed

_______________________________________________
jakarta.ee-steering mailing list
jakarta.ee-steering@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering
_______________________________________________
jakarta.ee-steering mailing list
jakarta.ee-steering@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering__;!!ACWV5N9M2RV99hQ!cXGaXw1xRSEbZjE9SSQlOERaWYb52t7okTg1xsKM5tswj1h-F6tmW--8BBXAknM$

--- End Message ---
--- Begin Message --- 
Hi Ed,

I'll do my best to answer all the questions.  If I miss anything it isn't intentional.

On will TCKs be included the short answer is, yes.  I wrote some guidance in this email:

 - https://urldefense.com/v3/__https://www.eclipse.org/lists/jakartaee-platform-dev/msg02940.html__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1ChbV7XMp7o$ 

On the use of "jakartaee" as the org, that was the expected outcome of the move.  The "jakarta-ee" org was described in the proposal as for demonstration purposes.  The "jakartaee" org is mentioned in the first sentence of the proposal, in our 2021 program plan and in the subject of the thread I started here in October attempting to get discussion/engagement before executing.  

I'm not sure I understand the comments around provisioning CI resources.  All the spec projects already have CI resources.  The only impact is that people may want to optionally update their existing Jenkins jobs once they move.  I say optionally as the old jobs will still work even if they point to the old location as Github will treat the old location as an alias.  Can you elaborate on what you see needs to be done?


-- 
David Blevins
https://urldefense.com/v3/__http://twitter.com/dblevins__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1Chblpq6CwQ$ 
https://urldefense.com/v3/__http://www.tomitribe.com__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1Chbil3dGGg$ 

> On Jan 10, 2022, at 11:20 AM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
> 
> Hi,
> 
> In 2019 the steering committee passed a resolution to separate Specification projects from Implementation projects. David had provided the following history:
> 
> 
>> - Proposal: https://urldefense.com/v3/__https://docs.google.com/document/d/1vQst9k0fOGhUbbw3RoOvi-BvjiSsADH4dyjqTquIwE8/edit?usp=sharing__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1ChbNiFQhbk$ 
>> 
>> - Approval: 
>> https://urldefense.com/v3/__https://jakarta.ee/about/meeting_minutes/steering_committee/minutes-june-11-2019.pdf__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1ChbxQF-56c$ 
>> 
>> - Breakdown: 
>> https://urldefense.com/v3/__https://docs.google.com/spreadsheets/d/1uoCebbw2ucpFO389VwTIEd6cqwBXhgE3Cq2fhS6g6ps/edit?usp=sharing__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1ChbsDCEDbU$ 
>> 
>> - Prototype: 
>> https://urldefense.com/v3/__https://github.com/orgs/jakarta-ee__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1ChbXrUVHXM$ 
> 
> Reviewing the proposal outline above, and comparing it to what is happening I am noticing that
> 
> 	• we aren't following the prototype and 
> 	• the results, as they are moving forward, at least to my eye, are confusing
> Is this what the committee was expecting? Do we want to make changes to what has already happened?
> 
> Details:
> 
> Some Specs. are being migrated out of the Eclipse-EE4J github organization. They appear to be migrated into the existing jakartaee GitHub organization (the hyphen between jakarta and ee has been dropped) instead of github.com/jakarta-ee, they are going into the existing github.com/jakartaee organization. 
> 
> When I look in the jakartaee Github organization, I'm noticing that it seems a bit confusing in that -- there are repositories that hold normative data (i.e. jakartaee/specifications) some that hold web-site data (e.g. jakarta.ee, jakartaone.org. jakartablogs.ee) and then the specification specific working repositories themselves (e.g. messaging, messaging-proposals, security, etc.).
> 
> I wasn't expecting this mixture of differing types of repositories. I think I'd imagined that there would be a separate specification specific organization and all the spec. working repositories would be in that. Then, a separate organization would hold all the final archives. To my brain, the most jarring thing is there's the jakartaee/specifications repository -- then there are each of the specification repositories (or sets of repositories) -- and this seems confusing to me.
> 
> Was this the expected outcome of this reorganization?
> 
> Do we anticipate that the TCK and other ancillary repositories will be migrated here too? I ask because I would like to keep the TCKs with the Specifications. If that's the case, then I think we will want to have Jenkins/CI resources available for this aspect of these projects -- so that those projects can consistently test changes to their TCKs. If there is agreement on that aspect, we probably want to make sure that, when a Spec. migrates to the new GitHub organization, it is also provisioned with a CI resource as well.
> 
> I'm not sure if this can be resolved in e-mail, or if this needs discussion time at the Steering Committee meeting.
> 
> Thanks,
> 
> -- Ed
> 
> _______________________________________________
> jakarta.ee-steering mailing list
> jakarta.ee-steering@xxxxxxxxxxx
> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1ChbjqRNdr0$ 

_______________________________________________
jakarta.ee-steering mailing list
jakarta.ee-steering@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1ChbjqRNdr0$

--- End Message ---
--- Begin Message ---
  • From: Ed Bratt <ed.bratt@xxxxxxxxxx>
  • Date: Mon, 10 Jan 2022 14:00:51 -0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wJzgS6vKyGp7ZkZA78VRYye71jp+lmFhOBysFb1fWr4=; b=RC0LbLCn/P4gO9J/C4WF83hKpHGFLiYIAh51AexWwyfVxVasRI1NZYm/DK0e9MPriTqdcTpoCN3oUMVM8gIQluDbS/idI3QlOIfJoVmrkyBbrtoi+UXA06cQFMU+k6j83lW3TewjlDuKs4RydMN80n8GnAuquvD3PoT6TAAElsWDoegQWgq0ELDMGVvshghXcCR9tcA3YtSRAcroGsboD8X/kb95lIR/g1N3Jczf7sfIBX56Us/WCfW542qVpVYt3WbXa9g0sDkyBHIPdqW277Hn5v/9BofNhx6OUpORUfqJ/6VntmQx+R1mBjRYvpLkVmhaQEoYciPlBjg92Mgp5Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mF2di/bXuSraL+9dkpqnLt2tGtOldF2jFsiSqpAPNHkwZVUZW7ognGKlDV2WrfpDYT6aiZtLe+7FMk6UmTQIL50+SpwhwPYaXQv8OqFvFBifYV1cAsSXZQSzRzmm84JuJMc1CGdDJsZOha9tacf9wCy8pQIMUeL8gP40VpGNTkdemmku/jfPXsE0fSAhSuC05UGkp4gvRDt7l2pf45MZDBoFlCFOh9JL1SVkZIgPV+r3OwthsNhb9vPiRZxmPD5/Z5McRSRizDEWRyHh1a1JmKnIFxZwT74LJFc8xYt+TcWDoW/rXzc4drqS0frRNZS0NZx52xYs/1ambXkCwtVVYw==
  • Delivered-to: jakarta.ee-steering@xxxxxxxxxxx
  • List-help: <mailto:jakarta.ee-steering-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering>, <mailto:jakarta.ee-steering-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/jakarta.ee-steering>, <mailto:jakarta.ee-steering-request@eclipse.org?subject=unsubscribe>
  • User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
David,

Thank you for your response.
Are you and other members satisfied with the organization content as it is coming together at github.com/jakartaee then? As I tried to point out -- to me at least, this presents in a confusing way when someone opens up the GHO repository URL (i.e. just github.com/jakartaee). I'm hoping that members have looked at the GHO contents and are satisfied this what we were intending to be the outcome of this resolution?
I understand that we must work within the limitations of the GitHub structure -- We can do anything we like with the web-site presentation but at the GitHub repository access level, we have to live with what GitHub provides.
If the committee is satisfied with this, we'll proceed as we are going. If not, now might be a better time to issue a revision to our instructions -- than sometime later. 

-- Ed

On 1/10/2022 1:12 PM, David Blevins wrote:

Hi Ed,

I'll do my best to answer all the questions.  If I miss anything it isn't intentional.

On will TCKs be included the short answer is, yes.  I wrote some guidance in this email:

  - https://urldefense.com/v3/__https://www.eclipse.org/lists/jakartaee-platform-dev/msg02940.html__;!!ACWV5N9M2RV99hQ!Y2xcNVscE9ztK4CgWxh9mIh1UIuPgrOT8PUXsYeA_6hY8dant3mN1ChbV7XMp7o$

On the use of "jakartaee" as the org, that was the expected outcome of the move.  The "jakarta-ee" org was described in the proposal as for demonstration purposes.  The "jakartaee" org is mentioned in the first sentence of the proposal, in our 2021 program plan and in the subject of the thread I started here in October attempting to get discussion/engagement before executing.

I'm not sure I understand the comments around provisioning CI resources.  All the spec projects already have CI resources.  The only impact is that people may want to optionally update their existing Jenkins jobs once they move.  I say optionally as the old jobs will still work even if they point to the old location as Github will treat the old location as an alias.  Can you elaborate on what you see needs to be done?



_______________________________________________
jakarta.ee-steering mailing list
jakarta.ee-steering@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering__;!!ACWV5N9M2RV99hQ!aztbEbLk97abEsKEeDAZ1yjVTaJsIyBs6RRnsKfq2HNnQdCNS7xxAaiChXwiltk$

--- End Message ---
--- Begin Message --- 
> On Jan 10, 2022, at 2:00 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
> 
> Are you and other members satisfied with the organization content as it is coming together at github.com/jakartaee then? As I tried to point out -- to me at least, this presents in a confusing way when someone opens up the GHO repository URL (i.e. just github.com/jakartaee). I'm hoping that members have looked at the GHO contents and are satisfied this what we were intending to be the outcome of this resolution?

>From the perspective of myself and Kevin who also helped work on the proposal, having the specifications in jakartaee was the goal.  In practice, it's looking good to me and definitely less confusing than the status quo of having a single eclipse-ee4j repo with 134 repos.  I'd personally be hesitant to add a third org and would find it particularly confusing if we were to use both jakartaee and jakarta-ee.  


-David

--- End Message ---
--- Begin Message ---
Hi,

Although this is not something we can solve here, or at all, core of the issue is perhaps the impossibility of github to properly support 2 or more level structures in an org.

github/jakarta-ee vs github/jakartaee doesn't seem any less confusing to me.

We probably either need a structured org organization, kinda like github/eclipse and github/eclipse-ee4j, or a repo organization, which would mean specific prefixes for each repo.

Just a thought, but e.g.

A repo organization could look like:

github/jakartaee/spec-faces
github/jakartaee/spec-pages
github/jakartaee/spec-authorization
...
github/jakartaee/normative-specifications
...
github/jakartaee/website-jakarta.ee
github/jakartaee/website-jakartaone.org
...
etc

A org variant would be:

github/jakartaee-spec/faces
github/jakartaee-spec/pages
github/jakartaee-spec/authorization
...
github/jakartaee-normative/specifications
...
github/jakartaee-website/jakarta.ee
github/jakartaee-website/jakartaone.org

Thoughts?

On Mon, Jan 10, 2022 at 8:21 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:

Hi,

In 2019 the steering committee passed a resolution to separate Specification projects from Implementation projects. David had provided the following history:

- Proposal: https://docs.google.com/document/d/1vQst9k0fOGhUbbw3RoOvi-BvjiSsADH4dyjqTquIwE8/edit?usp=sharing
- Approval: https://jakarta.ee/about/meeting_minutes/steering_committee/minutes-june-11-2019.pdf
- Breakdown: https://docs.google.com/spreadsheets/d/1uoCebbw2ucpFO389VwTIEd6cqwBXhgE3Cq2fhS6g6ps/edit?usp=sharing
- Prototype: https://github.com/orgs/jakarta-ee

Reviewing the proposal outline above, and comparing it to what is happening I am noticing that

  1. we aren't following the prototype and
  2. the results, as they are moving forward, at least to my eye, are confusing

Is this what the committee was expecting? Do we want to make changes to what has already happened?

Details:

Some Specs. are being migrated out of the Eclipse-EE4J github organization. They appear to be migrated into the existing jakartaee GitHub organization (the hyphen between jakarta and ee has been dropped) instead of github.com/jakarta-ee, they are going into the existing github.com/jakartaee organization.

When I look in the jakartaee Github organization, I'm noticing that it seems a bit confusing in that -- there are repositories that hold normative data (i.e. jakartaee/specifications) some that hold web-site data (e.g. jakarta.ee, jakartaone.org. jakartablogs.ee) and then the specification specific working repositories themselves (e.g. messaging, messaging-proposals, security, etc.).

I wasn't expecting this mixture of differing types of repositories. I think I'd imagined that there would be a separate specification specific organization and all the spec. working repositories would be in that. Then, a separate organization would hold all the final archives. To my brain, the most jarring thing is there's the jakartaee/specifications repository -- then there are each of the specification repositories (or sets of repositories) -- and this seems confusing to me.

Was this the expected outcome of this reorganization?

Do we anticipate that the TCK and other ancillary repositories will be migrated here too? I ask because I would like to keep the TCKs with the Specifications. If that's the case, then I think we will want to have Jenkins/CI resources available for this aspect of these projects -- so that those projects can consistently test changes to their TCKs. If there is agreement on that aspect, we probably want to make sure that, when a Spec. migrates to the new GitHub organization, it is also provisioned with a CI resource as well.

I'm not sure if this can be resolved in e-mail, or if this needs discussion time at the Steering Committee meeting.

Thanks,

-- Ed

_______________________________________________
jakarta.ee-steering mailing list
jakarta.ee-steering@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-steering

--- End Message ---

Back to the top