|
| 1 | +# 2025-11-05 Meeting Notes |
| 2 | + |
| 3 | +## Agenda |
| 4 | + |
| 5 | +- OCX attendance |
| 6 | +- Patching released Eclipse versions |
| 7 | + |
| 8 | + |
| 9 | +## Minutes |
| 10 | + |
| 11 | +### Status SimRel / 2025-12 |
| 12 | +- Overall good shape, some uncertainty regarding JUnit 6 support |
| 13 | +- Ed worked on SBOMs |
| 14 | + - Can check for CVEs in SimRel contents |
| 15 | + - Found CVEs that were resolved by updating Orbit or consumers |
| 16 | + |
| 17 | +### OCX Attendance |
| 18 | +- For some it depends on acceptance of talk proposal --> maybe ask again after decisions |
| 19 | +- Mélanie and Ed will attend anyway |
| 20 | +- Manoj, Mathias, Federico, Heiko have submitted or plan to submit |
| 21 | + |
| 22 | +### Patching Released Eclipse Version |
| 23 | +- Trigger: broken selection highlighting with MacOS 26.1 https://github.com/eclipse-platform/eclipse.platform.swt/issues/2621 |
| 24 | + - Major issue when using any released Eclipse version on MacOS 26.1 |
| 25 | + - Will only be resolved with next Eclipse release or by using I-Builds |
| 26 | + - Demands for allowing to patch released Eclipse versions |
| 27 | +- Motivation: not having to wait until next release, i.e., up to three month, when severe issues arise such as: |
| 28 | + - CVEs, in particular in core frameworks like Equinox |
| 29 | + - Compatibility breaks, such as new OS versions require changes in Eclipse (such as with the current MacOS issue) |
| 30 | + - Bugfixes, for unnoticed bugs with high impact that came into a release |
| 31 | +- Technical aspects of preparing / building patches |
| 32 | + - We already have maintenance branches, from which we can respin |
| 33 | + - They are disabled right after the release because of limited infrastructure capabilities |
| 34 | + - Would need to be on-demand builds |
| 35 | +- Technical aspects of / options for shipping |
| 36 | + - Possible via an update site |
| 37 | + - https://download.eclipse.org/releases is an automatically created composite with a strict structure -> we may not want to modify manually |
| 38 | + - For the platform/SDK there is already: https://download.eclipse.org/eclipse/updates/ |
| 39 | + - Update site like the ones above are already added to EPP products for the projects included in the package |
| 40 | + - One difficulty might be to produce an update site with minimal changes, only containing the modified artifacts |
| 41 | + - Use notifications and mechanisms like for supported Java versions after Eclipse releases |
| 42 | + - Uses a permanent marketplace entry |
| 43 | + - Creates a minimal, incremental update site |
| 44 | + - Can be realized via a feature patch |
| 45 | + - It might be difficult if natives (like Equinox launcher) are involved -> may need to be excluded? |
| 46 | +- Quality assurance of maintenance branches and derived patches |
| 47 | + - Maintenance branches may already contain other changes that have been backported |
| 48 | + - We need a process for when/what to backport to avoid untended |
| 49 | + - Proposal: provide patches for current, "stable" release |
| 50 | + - Limit backports for current release as much as possible |
| 51 | + - 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) |
| 52 | + - Proposal: ship patches (only) for current, "stable" release |
| 53 | +- Comparison to LTS approaches |
| 54 | + - Old LTS program from Eclipse Foundation: https://lts.eclipse.org/ |
| 55 | + - Was about fixing older releases even as an external company (not IBM) |
| 56 | + - There was extra infrastructure to provide according infrastructure |
| 57 | + - We should focus on having a stable release (i.e, patch current release if necessary) instead of LTS |
| 58 | +- Effort / costs |
| 59 | + - Lacking budget / capacities for keeping the maintenance branch builds working |
| 60 | + - Maybe we could use funded dev efforts contracts to support that work, given the demand and benefit of providing patches |
| 61 | +- Actions |
| 62 | + - Heiko takes the topic to the IDE WG to discuss relevance and potential funding |
| 63 | + - Sebastian tries to investigate what / how much needs to be done to support the discuss process |
| 64 | + |
| 65 | + |
| 66 | +## Next Meeting |
| 67 | + |
| 68 | +Next meeting will be on December 3th, 2025. |
0 commit comments