Releng for support for next Java versions

[stephan-herrmann]

In the ramp down phase of support for Java 23 we had quite some discussion how this could be improved in the future.

Some quotes as input for discussion here:

@akurtakov :

I am more and more convinced that PDE/JDT/Equinox should be their own separate releng procedures and scripts which projects can drive according to their taste and needs.

Pbuilds being only an update site should realy be maintained in one of the jdt repos (https://github.com/eclipse-jdt/eclipse.jdt fits best IMO) and JDT JIPP. That way all JDT committers will have full access and control over producing the update site.

@jarthana

In the past, the P builds also had PDE in them. So, it probably made sense at that time to have the releng scripts in the releng project. Would be nice if we can get them into jdt feature itself.
Also, what can we, the JDT committers, do to get permissions to kick off P builds and Y builds?

@akurtakov

Move them to https://ci.eclipse.org/jdt/ . This is not a different issue from Platform committers not being able to run https://ci.eclipse.org/jdt/job/copyAndDeployJDTCompiler/ .
It's a possibility to add 1-2 JDT committers manually to some jobs (IIRC that gives the permission to edit the cron pattern but doesn't give direct run permission) but this would be overriden whenever https://ci.eclipse.org/releng/job/Create%20Jobs/ is run (and it's the only way to edit all jenkinsfiles and redeploy in one go and there are so many different scripts) and the manually added committers will have to be readded

@sravanlakkimsetti

I am open if someone else can take up the alternative approach to provide a P build.
btw, for the record, I also do not think highly of the current patch build process as it is too fragile with too many hacks. Lets migrate the patch build to the better one you suggested if someone else can pick it up now or for the next (Java24) release atleast.

Calmly thinking about the options after the dust of Java 23 has settled, I'm not sure which steps would provide the best solution, so I'm opening this discussion here before we go into technical details.

[stephan-herrmann]

As a first statement of my own I'd like to express the hope that this is not perceived as an attempt of either party to offload unpleasant work to some other party.

JDT cannot expect platform releng to perform miracles again on last minute with requirements that are not clearly communicated.

OTOH, I'd like to caution against considering a patch feature private business of JDT. This is the main channel for publishing a Java IDE for the most recent Java version. So, anybody interested in making the Eclipse Java IDE a success should be very much interested also in successfully building and publishing these patch features. The only way to streamline the process without the need for such patch features would be by aligning the release schedules of Oracle and Eclipse, so that on the day of a new Java version's GA Eclipse can deliver a regularly built and fully tested IDE for that version. Unless someone makes a move in this direction, patch features are the way to go twice a year.

Realizing that platform is not solely and entirely focused on Java IDE, I wonder if the IDE WG should be the actor to ensure we have the resources to deliver.

Another way to ask this: is dedicated responsibility for releng tasks a success story in Eclipse, or do we / should we expect every team to have a member specialized in releng topics?

[akurtakov]

I fully agree on the implications to the broader ecosystem but my statements are based on the ground that JDT committers should have full access to all the things needed for the P-build releases. EF rules are that only committers have access to project resources, git repos, jenkins, etc.
This makes running the patch builds happen on JDT project resources the most stable and sure that nothing is missed solution..

[stephan-herrmann]

Perhaps, we don't need any drastic change. To find out, @sravanlakkimsetti do you have any suggestions how the patch build can be streamlined so that you don't have to jump in again and again, i.e. so that anybody with basic releng knowledge can maintain it? How hard would that be?

[jarthana]

Perhaps, we don't need any drastic change. To find out, @sravanlakkimsetti do you have any suggestions how the patch build can be streamlined so that you don't have to jump in again and again, i.e. so that anybody with basic releng knowledge can maintain it? How hard would that be?

I think so too. What made it complicated this time was, we had a new dependency and we were trying it all very late in the game. Obviously, we will address the latter first. I and Manoj discussed about having an milestone within BETA release itself to address all the releng tasks.

[sravanlakkimsetti]

I think we should go towards as @merks suggested path. He is able to generate the patch repo using

mvn clean verify -Pbuild-individual-bundles -Duser.home=D:/Users/test35 -DfeatureToPatchVersion=3.19.600.v20240903-0240 -DfeatureToPatch=org.eclipse.jdt

This will eliminate

1. Patch profile in aggregator
2. Missing out on inclusion of modified plugins. Happened multiple times.
3. Unnecessary dummy bundles

We should explore the way @merks has suggested. This looks drastic change on the face of it. but I feel its much more simpler than the existing patch build process

[mpalat]

I would also like to add some intermediate milestones from next BETA_JAVAXX (24+) onwards which will have issues that are not JEP related - read P Build, Y build, test framework etc. It can follow a similar milestone structure of Eclipse Platform albeit with a longer duration (totalling six months). Opinions welcome

[stephan-herrmann]

Such a milestone sounds great. 👍

Thinking aloud:

• BETA_JAVAX M1 after SimRel ships the first M2 within the 6-month Java cycle? E.g., late October? I suggest we keep clear of the time around any Eclipse releases, to avoid putting stress on stressed people. That milestone could target:
  • new compliance levels in place in the implementation
  • successful (and tested) Y and P builds
  • start of (at least) weekly Y builds
• BETA_JAVAX M2 after the second SimRel M1 within the same 6-month cycle, focus:
  • Y-Tests are clean on all platforms
  • start daily Y and P builds
  • let summary of test results be emailed to people involved?

Then only one thing still needs to be done very late: update the patch feature to refer to the fresh release from master.