Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cu-dev] : Re: Release process for Concurrency 3.0 spec
  • From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
  • Date: Mon, 18 Apr 2022 16:25:30 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=us.ibm.com; dmarc=pass action=none header.from=us.ibm.com; dkim=pass header.d=us.ibm.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=pVeIx6J47EnCsOAzi0nLQiabpOPcPFG7ChcwE3yzCoY=; b=GjEXN5BQO1XGnESfj+rjS9xLQ/FNC+J70rZKz5qZKFGJX10Bd2apAOXDWhcirXl6z1jVdaJBjFcFtHe5kBgDwre2qh/TgheM62lHPmYxjstf5BvF8/Wuq0zAnLG3YDx4uS28WVCOM6Ai1C1x7Eik4GxaCCuGtq8/3HdGX83x+mMgBuLkj+is0H6tu8gHkNCqUTu8ThPxH9eLbOE27+FMeiEV/2Q55RWno/AVGCBQzxxmJ97aYItJGaqqxquGpN+yNw6uUQLzRKSkg4zC20WOnCgxIOw3tww/3JB9lFZOFfhoXl6U20fooQbwn8qJixoG0z9fi5Q2q7iOFUIjD7rw2w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lM6bD5rBYmewRbmQFTad8Fyu2OsghEPmalqxkkK+er3N+ihJeM94wyhzVRZkwDo811O2tWkGy2uhI9LgeDlfaTrqPLbI3iJsZUsgI7oFsK4Ubh3ZN1uX1CoAeRQpwtS2u6I9HPt0YjYBGDT9d/e1t1Y/NM6+Pt77B/14l/dkUGr5Nl7+pF6QYreROCKrIVLjjGokaR04msBO6Y+YOlGiKIevJt7247aaCLjRdJXRDnOB8EJ1pnkC2gppY9pVXOF36eWHAEMGXa3fnJofFIPJXzKk5vAkcLDiop1ZNQJvoTMKs5zKOPPIEki67ZbeTJvo3QuEWyd8SqO+b3ypkN5TmQ==
  • Delivered-to: cu-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/cu-dev/>
  • List-help: <mailto:cu-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AQHYUzjPjr7aWW7oM0+fXzVY+YdBfaz1h5MA
  • Thread-topic: [EXTERNAL] Re: [cu-dev] : Re: Release process for Concurrency 3.0 spec

Scott,

 

To clarify, I see the other Jakarta EE 10 specs with their own specification TCKs, such as JSON-B and JSON-P, using the jakartaee-tck location.

 

From JSON-B’s https://github.com/jakartaee/specifications/pull/456 :

The URL of the staging directory on downloads.eclipse.org for the proposed EFTL TCK binary:
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/promoted/eftl/jakarta-jsonb-tck-3.0.0.zip

 

From JSON-P’s https://github.com/jakartaee/specifications/pull/432 :

The URL of the staging directory on downloads.eclipse.org for the proposed EFTL TCK binary:
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/promoted/eftl/jakarta-jsonp-tck-2.1.0.zip

 

Both of those release reviews are marked approved and closed, so I assume Concurrency 3.0 for EE 10 ought to follow the same pattern and use jakartaee-tck as well and that your comments about using a different location are directed at EE 11.  It wasn’t clear from your previous reply if “future Concurrency releases” included EE 10 or not given that 3.0 isn’t released yet.

 

 

From: Scott Marlow <smarlow@xxxxxxxxxx>
Date: Monday, April 18, 2022 at 10:27 AM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>, Nathan Rauh <nathan.rauh@xxxxxxxxxx>, "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [cu-dev] : Re: Release process for Concurrency 3.0 spec

 

On 4/18/22 11:10 AM, Nathan Rauh wrote: Steve, The specification checklist item for TCK states “The URL of the staging directory on downloads.eclipse.org for the proposed EFTL TCK binary” ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

 

On 4/18/22 11:10 AM, Nathan Rauh wrote:

Steve,

 

The specification checklist item for TCK states “The URL of the staging directory on downloads.eclipse.org for the proposed EFTL TCK binary”

Based on the corresponding pulls for other specifications, my guess would be that we need to get our proposed final copy of the TCK uploaded here,

 

https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/staged/eftl/

 

although I also see,

https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/staged/epl/

I believe that the SPEC team does update the licensing of the TCKs to EFTL if not done already when releasing the TCKs.  For the Concurrency TCK, the released zip would go to https://download.eclipse.org/jakartaee/concurrency/3.0 so future Concurrency releases, we might want to stop using the https://download.eclipse.org/ee4j/jakartaee-tck path when staging new Concurrency TCKs.

 

Oddly enough, there appears to be zips for Concurrency 3.0 TCK already present under both of these, which I am guessing is the old platform TCK.  I wonder if we will need to do something to disable the old platform TCK to keep it from colliding with the new one or if it’s good enough just to overwrite with the new one.

https://ci.eclipse.org/jakartaee-tck/job/10/job/eftl-standalonetck-build-run-100 removed concurrency from list of TCKs built from Platform TCK and https://github.com/eclipse-ee4j/jakartaee-tck/pull/816 also was merged last week as well which removes the old Concurrency tests from Platform TCK.

The

 

I also see corresponding locations for promoted,

https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/promoted/eftl/

https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/promoted/epl/

which as expected does not yet have a Concurrency 3.0 TCK.

 

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Kyle Aure <kylejaure@xxxxxxxxx>
Reply-To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Date: Monday, April 18, 2022 at 9:27 AM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] [External] : Re: Release process for Concurrency 3.0 spec

 

Hey Steve,

 

I believe if you look at the Concurrency API Release Build (https://ci.eclipse.org/cu/job/concurrency-api-release-build/configure)

You will see a similar script that releases the Concurrency API to the stagging repository.

We should be able to just re-use that script.

Though I'm not sure if the secret file is build specific, or a general file all builds can use so we may need guidance on that if it is inaccessible.

 

Thank you,

Kyle Jon Aure

 

On Mon, Apr 18, 2022 at 5:24 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

Hi All,

 

I checked Kyle and Scott’s work and tweaked the Jenkins job to pick up the zip. I now believe we have a Jenkins job that is generating a valid TCK distribution see Jakarta Concurrency - Concurrency TCK Master Build [Jenkins] (eclipse.org) zip file.

 

What I don’t know is where it has to go? Do we upload onto the project download server or somewhere else? Once I know I can create a Jenkins job that uploads to somewhere.

 

Once this is done I’m not sure what else we have to do other than get through the tick box on the PR Concurrency 3.0 release review by njr-11 · Pull Request #449 · jakartaee/specifications (github.com) this isn’t normally too onerous.

 

Let me know if I am missing something that still needs to be done.

 

Steve

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Ed Bratt
Sent: 30 March 2022 00:38
To: cu developer discussions <cu-dev@xxxxxxxxxxx>; Scott Marlow <smarlow@xxxxxxxxxx>
Cc: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
Subject: Re: [cu-dev] [External] : Re: Release process for Concurrency 3.0 spec

 

Sorry, I don't know if this is still an issue -- in the Platform TCK, their build process creates two sets of TCKs -- one that packages the release ZIP with the project license (EPL + GPL v2 w/CpE) and another that uses the EFTL license. They do NOT modify any of the source license headers, nor anything else that I know of. So, the only change is to swap out the "top-level" LICENSE.md file. This could be done as a simple substitution, or as part of your build pipeline. As a reference example, compare the top directory in soap-tck-3.0.0.zip/soap-tck/LICENSE.md vs. jakarta-soap-tck-3.0.0.zip/soap-tck/LICENSe.md in

·        EFTL SOAP Attachments TCK

·        EPL SOAP Attachments TCK

You should see that there are no differences between these two archives except for that license file. (The file names do differ but that's more a convenience to tell the two apart than anything else.)

Since Eclipse Foundation hasn't provided triple license text/mark-down files, I recommend you just make two distributions. The EFTL copy will be copied up to the "official" specification download folder. The project license TCK can be used by anyone but doesn't contain the provisions necessary for application of the actual certification approval.

This should not have any impact on any product bits although technically, for certification, you must use the TCK from the release that includes the EFTL and when you submit your certification, you will need to reference the EFTL, final (or proposed final) TCK. So, there may be additional testing obligations, but the TCKs shouldn't be included in anything you ship.

As for producing the TCK -- (if that's what you mean by "shipping") -- you may make the EPL TCK available anywhere you like. Some projects use the Eclipse download server. Some project rename the extension to .jar and push the zip to Maven central. As for the EPL copy, our process requires that the proposed file TCK be pushed to the eclipse download site -- the Spec. committee mentor (me) will push it up to the official download folder, once the ballot is completed. The Platform TCK project just leaves these released TCKs on their download server.

For the purposes of certification -- what is important is that you use tests that come the file that has the same SHA sum hash. This doesn't change if the file is moved from one download location to another, nor even if the file name changes. But the hash will change if any of the content changes. So -- once you have the proposed file TCK zip -- make your final certification test run, capture the results -- With those, you can complete the CCR issue using the SHA sum hash and that won't change by virtue of any of the final release processing we do once the Spec. ballot is completed so ... there won't be any need to re-run the tests, once the TCK zip is moved into it's final d/l spot.

Let me know if you have more questions.

-- Ed

 

On 3/25/2022 7:53 AM, Scott Marlow wrote:

https://github.com/eclipse-ee4j/concurrency-api/issues/196 has some guidance on options to copy the TCK documentation over to the Concurrency TCK.  I don't think that has been done yet.

 

Scott

 

On Tue, Feb 15, 2022 at 4:56 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

Hi Nathan,

 

I can attempt to take over the process stuff although I also do poorly with it, I’m not familiar with it and don’t understand it. I will therefore require a lot of support from someone who does get the process stuff. It’s not obvious to me from the comments below what are the key things that need doing to get this over the line can someone spell out the tasks in simple words 😉.

 

I’m not sure how adding a license to the TCK will require you to release a new Beta of OpenLiberty although I take your word on that.

 

Can one of the mentors answer the question RE: shipping a jar as part of the TCK. I am definitely not familiar with shipping a TCK? I am also not too familiar with the work done to bring the TCK into this project from the old TCK project.

 

I will take a look at the Javadoc generation.

 

Thanks

 

Steve

 

 

 

From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 14 February 2022 17:11
To: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>; cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>; Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: RE: Release process for Concurrency 3.0 spec

 

I need help with some of the comments that have been raised (mostly around license issues) in the release review issue under https://github.com/jakartaee/specifications/pull/449

“The TCK must be licensed under the EFTL. For distribution via Maven, the TCK may be dual licensed: EFTL + EPL. Please revise the tom-level license docs and discard the EPL + GPL v2 license docs. Source-code license headers need not be updated.”

Could someone who knows what they are doing with licenses correct the above?  Does this require re-building the candidate final copy of the TCK?  If so, this will push us out a month (if we can get everything corrected and rebuilt within a week) and otherwise longer because our candidate compatible implementation will need to publish another beta upon which we can run any updated TCK.

“I will need to get clarification from the Spec. committee about the final distribution of the TCK materials. Current check-list requirement is that we provide the TCK as a complete bundle .zip file that is linked to the controlled Specifications download folder. For CU 3.0, this would be: download.eclipse.org/jakartaee/concurrency/3.0/jakarta-concurrency-tck-3.0.0.zip -- You can use the CU 2.0 archive to review the contents if that is helpful. Also please review the Mentor Checklist items 6, 7, and 8 for additional details.”

If I understood the above correctly, it sounds like splitting the TCK out of platform and building it in our main project might not fit with some of the rules, although I know several other specifications are doing the same.  Our TCK is a JAR file suitable for publishing to Maven, not a ZIP,
https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-tck/3.0.0/
Hopefully, Ed will be able to get clarification allowing us to continue using this approach, and that would seem to cover most of the troubles with getting sections 6, 7, and 8 checked off, but I also see a checkbox asking for a “EFTL license file, preferably named LICENSE.md” which we don’t have in our TCK, which goes back to the first issue mentioned.

“I do see that there is a docs folder in the Maven source archive. This only includes the license file. Lacking further documentation, I would recommend this release use the previously created cu 2.0 TCK zip as the proposed list of contents -- if anything is to be discarded, we can explicitly decide to remove it.”

I don’t understand the above. Hopefully, someone else does.


“The Java doc link to the Spec. License HTML file yields 404 in the Netlify preview. Please correct if needed.”

 

I tracked down the above to
https://deploy-preview-449--jakartaee-specifications.netlify.app/specifications/concurrency/3.0/apidocs/
which has some fine print at the bottom of the page with a copyright “license terms” broken link to
https://deploy-preview-449--jakartaee-specifications.netlify.app/specifications/concurrency/3.0/apidocs/doc-files/speclicense.html

 

Sure enough, our generated 3.0 javadoc jar file,
https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-api/3.0.0/jakarta.enterprise.concurrent-api-3.0.0-javadoc.jar

doesn’t have any doc-files/speclicense.html

unlike the 2.0 javadoc jar file, which does have it,

https://repo1.maven.org/maven2/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-api/2.0.0/jakarta.enterprise.concurrent-api-2.0.0-javadoc.jar

 

What changed here that got rid of this and how to correct it?  I assume this will require re-building everything (once a fix is made) rather than just grabbing the copy from the 2.0 jar and checking that in.

 

Would someone else be willing to take over at this point sorting out the process stuff?  This is an area that I do poorly with and I’m not even the lead for this spec.

 

 

From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: Wednesday, February 9, 2022 at 9:12 AM
To: Nathan Rauh <nathan.rauh@xxxxxxxxxx>, cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>, Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: [EXTERNAL] RE: Release process for Concurrency 3.0 spec

 

Hi Nathan,

 

As you are a committer I think you can do those things which is why you get can get so far. I don’t remember a lot of the process. I see you have added Ed/Dmitry I think they are our mentors available to us to help guide us through this part of the process.

 

Steve

 

From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 08 February 2022 17:44
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>; Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>; Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: Release process for Concurrency 3.0 spec

 

Given that we’re supplying the candidate for compatible implementation and have the information for it and the results and so forth, I’ve been trying to fill out some of the process for the 3.0 release based on this, and I’ve been surprised how far it seems to be letting me go without any additional authorization.  Thus far I have the following two issues mostly filled out (some links within the checklists won’t be working until a week from now) and it even allowed me to update the release record to replace the projected release date of last October with Feb 28 and to request a Generated IP Log, although I have no idea if I’ve done those things properly or if I should have included more information.  To any of you who know what you are doing with this sort of process, please review and correct or fill in parts that I have missed.  I’m hoping that we will be able to check off the remaining boxes and submit the release review a week from now.  If anyone else would like to take over, I’d be happy to let them.

 

Concurrency 3.0 release review issue:

https://github.com/jakartaee/specifications/pull/449

 

Concurrency 3.0 compatibility certification request issue:

https://github.com/eclipse-ee4j/jakartaee-platform/issues/464

 

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

 

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

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



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

Back to the top