Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] ACTION: Eclipse GlassFish release plan
What if there are failures at this stage do we have to go back to release review or should this step be before release review?
 
No, release review doesn’t require having all dependencies updated. It has to be done once and before releasing artifacts to Maven Central. It’s allowed to make changes after release review is passed. Wayne can explain it better than 

The EDP states that "The purposes of a release review are: to summarize the accomplishments of the release, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the principles and purposes of Eclipse." 

In effect, the Release Review is concerned (mostly) with ensuring that processes are being correctly followed (I can expand on this if there's interest). We use a Release Review to confirm that the project is following the IP Due Diligence Process by checking their IP Log. There is no requirement to lock down development while we engage in a Release Review or for any time after. It's generally expected that no new features are added or otherwise significant changes are made to the release version after the review, but it's completely normal for bugfixes to be applied. Many project teams will include some "quiet" period during their ramp down plan, but's separate from the review.

A Release Review can, however, theoretically fail. Theoretically, it's good practice to set them up some amount of time before you plan to actually release so that there's some room to mitigate issues. In practice, however, I don't recall a Release Review ever failing (we set them up to succeed) and so we tend to schedule reviews very close to the planned release date. The issues that we do discover tend to be relatively easy to mitigate (e.g. update CONTRIBUTING files, etc.).

Wayne

On Thu, Sep 13, 2018 at 7:46 AM, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:


On 13 Sep 2018, at 12:16, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

I have some observation on this below.

TL/DR
The plan is very aggressive and will need a lot of resourcing.

I’ll try to explain. 

-----Original Message-----
From: ee4j-pmc-bounces@xxxxxxxxxxx <ee4j-pmc-bounces@xxxxxxxxxxx> On Behalf Of Dmitry Kornilov
Sent: 12 September 2018 21:11
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Subject: [ee4j-pmc] ACTION: Eclipse GlassFish release plan

Hi,

As we agreed earlier sending you the proposed EclipseFish release plan. I has to be approved by PMC. Please make your votes. I am voting +1.


Eclipse GlassFish release plan:

Sep 18 -- All code required for GF build contributed.

I am glad that you have no objections here. :)

Sep 23 — Eclipse GlassFish builds.

Builds against what? 3rd party Modules currently hosted in java.net maven or modules hosted in maven central/OSSRH or modules hosted somewhere in Eclipse? The answer to this question determines how easy it is to get to this milestone.

This deadline assumes that GlassFish CI/CD build pipeline works and GlassFish builds with _current_ dependencies. It doesn’t require that all dependencies are changed/switched to Eclipse EE4J components. Deadline for that is Nov 30.

Is it building with -DskipTests or with all tests passing?

Cheating is not allowed. :)
This is mainly Oracle task. Eclipse GlassFish at that stage supposed to be the same as in the Java EE repository. It must be buildable and QuickLook tests must be passing. 

Oct 1 -- Java EE 8 CTS testing. We are able to run CTS tests on Eclipse GlassFish.

Never seen the CTS so I have no idea how big a task that is.

This is an Oracle task. At this stage we should be able to test Eclipse GlassFish with Java EE CTS/TCK binaries. Passing all CTS/TCK tests is not a requirement.

Oct 1 — CI/CD release pipelines completed.

What are we building in the CI/CD release pipeline the glassfish.zip for full profile or all modules created during the build also pushed to OSSRH?

Getting a Jenkins pipeline up and running building GlassFish against any PR is non-trivial and may require changes to the Jenkins infrastructure in terms of capacity this is not just 1 or 2 jars you are building? For a reference point we spent literally months putting together a stable Jenkins pipeline for Payara that could also run all tests reliably and it still breaks too often.   

It’s just about competing all CI/CD work here: https://github.com/orgs/eclipse-ee4j/projects/1. We should be able to release all components to OSSRH at that stage. Integration to GlassFish is not a goal.

Oct 21 — Dependencies updated. All projects are released to OSSRH and have dependencies to Eclipse version of other components.

This requires ALMOST ALL other EE4J projects to have made a release to OSSRH of both API and RI this is extremely challenging and depends on many other projects. Also how are these other projects going to test their RI has passed their TCK or are they skipping that test?

It’s ALL without almost. I started to prepare a tracking page listing all components version which will be included in GlassFish; https://github.com/eclipse-ee4j/ee4j/wiki/GlassFish-components-release-tracking

This task doesn’t assume that all components are integrated to GlassFish and passing all CTS/TCK tests. It just assumes that we released all of them to OSSRH and dependencies are resolved. 

After that we should integrate components one by one to Eclipse Glassfish, run CTS/TCK tests and fix integration errors. There is time until Nov 30 to do it. It will be tough.

There are a huge number of dependencies to be updated checked in and PRs tested. Is this one PR or lot of little PRs when each module is released. Ideally you would have each dependent project make a PR to the GlassFish source when they have released to OSSRH.

Are you talking about GlassFish PRs? I see it as many PRs and the full CTS/TCK tests suite must be run for each of them. If not passed, GlassFish team should evaluate failures and reject the PR (if it breaks a lot) or integrate it and file a bug for developers to fix (if there are only minor updates required).

It’s difficult to predict how it will go. There shouldn’t be many changes in the components. Only critical fixes were allowed to be merged to EE4J_8 branches. So, I assume there won’t be many failures. But I can be wrong. We will see how it goes and possibly move this deadline forward.

Oct 22 -- Eclipse GlassFish 5.1-RC1 milestone release.

Again what are we releasing GlassFish Full Profile, Web Profile, Embedded, Minimal, All of them etc?

All of them. This deadline doesn’t require passing all CTS/TCK tests, but it does require passing all minimal QuickLook acceptance tests.

Nov 16 -- Release Review completed.

Nov 30 -- Eclipse GlassFish 5.1 release. All CTS tests are passed.

What if there are failures at this stage do we have to go back to release review or should this step be before release review?

No, release review doesn’t require having all dependencies updated. It has to be done once and before releasing artifacts to Maven Central. It’s allowed to make changes after release review is passed. Wayne can explain it better than me.

Thanks,
Dmitry
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.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://dev.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://dev.eclipse.org/mailman/listinfo/ee4j-pmc




--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation

Back to the top