From d0bee1a73289dafdd1a5e7ea9eb8c2eb201ae400 Mon Sep 17 00:00:00 2001 From: Heiko Klare Date: Wed, 5 Nov 2025 09:20:18 +0100 Subject: [PATCH] Meeting notes for Planning Council 2025-11-05 --- wiki/Planning_Council.md | 1 + wiki/Planning_Council/2025-11-05.md | 68 +++++++++++++++++++++++++++++ 2 files changed, 69 insertions(+) create mode 100644 wiki/Planning_Council/2025-11-05.md diff --git a/wiki/Planning_Council.md b/wiki/Planning_Council.md index 649d299..c672411 100644 --- a/wiki/Planning_Council.md +++ b/wiki/Planning_Council.md @@ -63,6 +63,7 @@ Telephone Dial in (for higher quality, dial a number based on your curr ### Meeting Minutes + - [2025-11-05](Planning_Council/2025-11-05.md) - [2025-10-01](Planning_Council/2025-10-01.md) - [2025-09-03](Planning_Council/2025-09-03.md) - [2025-08-06](Planning_Council/2025-08-06.md) diff --git a/wiki/Planning_Council/2025-11-05.md b/wiki/Planning_Council/2025-11-05.md new file mode 100644 index 0000000..f37b2b7 --- /dev/null +++ b/wiki/Planning_Council/2025-11-05.md @@ -0,0 +1,68 @@ +# 2025-11-05 Meeting Notes + +## Agenda + +- OCX attendance +- Patching released Eclipse versions + + +## Minutes + +### Status SimRel / 2025-12 +- Overall good shape, some uncertainty regarding JUnit 6 support +- Ed worked on SBOMs + - Can check for CVEs in SimRel contents + - Found CVEs that were resolved by updating Orbit or consumers + +### OCX Attendance +- For some it depends on acceptance of talk proposal --> maybe ask again after decisions +- Mélanie and Ed will attend anyway +- Manoj, Mathias, Federico, Heiko have submitted or plan to submit + +### Patching Released Eclipse Version +- Trigger: broken selection highlighting with MacOS 26.1 https://github.com/eclipse-platform/eclipse.platform.swt/issues/2621 + - Major issue when using any released Eclipse version on MacOS 26.1 + - Will only be resolved with next Eclipse release or by using I-Builds + - Demands for allowing to patch released Eclipse versions +- Motivation: not having to wait until next release, i.e., up to three month, when severe issues arise such as: + - CVEs, in particular in core frameworks like Equinox + - Compatibility breaks, such as new OS versions require changes in Eclipse (such as with the current MacOS issue) + - Bugfixes, for unnoticed bugs with high impact that came into a release +- Technical aspects of preparing / building patches + - We already have maintenance branches, from which we can respin + - They are disabled right after the release because of limited infrastructure capabilities + - Would need to be on-demand builds +- Technical aspects of / options for shipping + - Possible via an update site + - https://download.eclipse.org/releases is an automatically created composite with a strict structure -> we may not want to modify manually + - For the platform/SDK there is already: https://download.eclipse.org/eclipse/updates/ + - Update site like the ones above are already added to EPP products for the projects included in the package + - One difficulty might be to produce an update site with minimal changes, only containing the modified artifacts + - Use notifications and mechanisms like for supported Java versions after Eclipse releases + - Uses a permanent marketplace entry + - Creates a minimal, incremental update site + - Can be realized via a feature patch + - It might be difficult if natives (like Equinox launcher) are involved -> may need to be excluded? +- Quality assurance of maintenance branches and derived patches + - Maintenance branches may already contain other changes that have been backported + - We need a process for when/what to backport to avoid untended + - Proposal: provide patches for current, "stable" release + - Limit backports for current release as much as possible + - Require PMC+1 for backport changes to current release (or some other way of "police" for limiting number of backports/patches to the absolutely necessary) + - Proposal: ship patches (only) for current, "stable" release +- Comparison to LTS approaches + - Old LTS program from Eclipse Foundation: https://lts.eclipse.org/ + - Was about fixing older releases even as an external company (not IBM) + - There was extra infrastructure to provide according infrastructure + - We should focus on having a stable release (i.e, patch current release if necessary) instead of LTS +- Effort / costs + - Lacking budget / capacities for keeping the maintenance branch builds working + - Maybe we could use funded dev efforts contracts to support that work, given the demand and benefit of providing patches +- Actions + - Heiko takes the topic to the IDE WG to discuss relevance and potential funding + - Sebastian tries to investigate what / how much needs to be done to support the discuss process + + +## Next Meeting + +Next meeting will be on December 3th, 2025.