Reason for feature-freeze period?

[tmssngr]

What is the exact reason for the feature-freeze period? Is it because the CI does not support different branches?

[merks]

Generally we're frozen from when M3 drops (technically on this just past Saturday) until RC2 drops on May 28. RC1 is May 21.

As soon as RC2 drops, @HannesWell prepares the cycle for 4.41 and opens master as soon as there are build for master producing 4.41 update sites. He also creates a branch for 4.40 at that point and sets up builds to build that branch. Ideally (in some dreamworld), folks would be heavily testing master right now to ensure a high quality release with fixes for any severe problems that we don't want to ship in the release. So of course we're still open for fixing regressions and severe problems, but not for feature enhancements or risky changes; test fixes and documentation improvements are also still open and welcome.

[HeikoKlare]

I agree that this is also particularly a means to highlight the purpose of this phase: testing and stabilization

We should keep in mind that even without explicit, intensive testing, we have the implicit testing of the current development state via the I-Build-based IDEs usually used by developers. So those IDEs would be supposed to stay on the current release cycle state, which would limit the benefit of already merging something for the next release cycle, as you do not test it in you daily IDE.

The teams I have worked with have worked on larger feature streams in the past (such as the monitor-specific scaling in SWT) and during freeze period quite some changes summed up, but it was never a larger issue for us. So I don't expect it to be an issue for the common, usually rather isolated changes to just wait for two week for being further processed.

[tmssngr]

In our product we introduced following testing:

• each feature is developed in its feature branch
  • the developer regularly rebases it onto develop
• if the feature is ready for team-testing, we rename the branch to have prefix "experimental/" (experimental branch)
• for (team-testing) experimental builds a separate branch "deploy/experimental" exists
  • when building a new experimental build, "deploy/experimental" is reset to develop and merges all experimental branches
  • if there are minor bugs in a new experimental branch, they are fixed in their experimental branch (fixes come into the next experimental build)
  • if experimental branches are too buggy, they are downgraded again to not be experimental branches again
• after a couple of days/weeks of testing, experimental branches are cleaned up, then merged/rebased into/onto develop, if there were no complaints
• regular public builds are built from develop
• this helps us to test-drive brand new features without having to carved them already in stone (= develop), develop became more stable, reverse-merges became very rare
• maybe such a branching model would make sense for SWT, too?

[akurtakov]

Effectively this is the model already:

• PR == feature branch that's cleaned up and ready to be merged in according to its author
• For each PR there are builds to try out e.g. https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-3309/1/artifact/
• Feature freeze is only for merging PRs into master (your develop branch)
• Nothing prevents people to work on their branches/PRs

What do we miss?

[tmssngr]

@akurtakov Where is the build that integrates the latest waiting PRs into one? Do you test each PR build? I test mine, but not those from others.

[akurtakov]

There is no such build. But we are already struggling with resources e.g. https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4231 so I would dare to say it's not even feasible with current resources - SWT builds are fighting for resources with I-builds/Y-builds/tests/etc.

The Eclipse Platform project always appreciates when member companies assign resource packs to the project to make our lives slightly easier.

At https://api.eclipse.org/cbi/sponsorships one can see that Eclipse Platform JIPP has only 1 Resource pack from Red Hat and 2 from IBM. As this one has zero agents it can't be used for SWT development .

Releng JIPP (the one that produces Platform, SWT, JDT, Equinox builds and tests) has 1 dedicated agent and 3 resource packs by Red Hat, 2 agents and 3 resource packs by IBM, 1 agent by Bosch, 1 resource pack by Vector.

1 Dedicated agent is what is needed for each OS on each architecture - aka 2 for Windows (x86_64 and arm64), 2 for Mac (x86_64 and arm64), 3 for Linux (arm64, ppc64le and riscv64) . Luckily Linux/x86_64 can be covered on a resource pack. Before anyone asks why there are ppc64le or riscv64 agents - they are there because a company decided to sponsor it.

If we want to run our tests on e.g. oldest and newest Mac or Windows this will double the agents for each of them.

That should explain why such builds are not feasible now.