Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

[cross-posted to epp-dev mailing-list]

That means that the "Eclipse IDE for Rust developers" package should not appear on the page. To be honest, it's not a big deal, I'll adjust links from Corrosion README so they point to the internal EPP download area. So if you wish to proceed with removal now, feel free.

The parts about signing are more a reminder of current rules, so no impact here. However as Alexander mentioned, I think it's worth exploring alternative approaches to signing if we want to innovate faster. The whole world, including the majority of active Eclipse Foundation projects, except Eclipse SimRel participant, manage to go round without jarsigner. If we want SimRel to remain in touch with this world, able to consume new APIs and so on more easily, in the continuation of all efforts done to improve 3rd-party approval from IP perspective, we need to find a more efficient way to deal with external artifacts that are unsigned. Orbit doesn't go fast enough anymore...

On Fri, Jan 22, 2021 at 4:23 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
As the recent SolarWinds hack has reminded us, security is everyone's concern. We owe it to the millions of developers and adopters who use our technologies to take all reasonable steps to ensure the validity of the software that we distribute.

Responsibility to decide which Eclipse IDE packages are distributed as official "Eclipse IDE" releases (e.g., the packages listed on the Eclipse IDE packages download page or are installable via the installer) rests with the Eclipse Foundation. That is, the Eclipse Foundation has (and has always had) responsibility to ensure that the content being distributed as official "Eclipse IDE" releases meets a well-defined standard. 

The standard is set by the participation rules of the simultaneous release and following the practices established for the simultaneous release, are in our opinion, the best means of mitigating risk.

In order for a package to be listed as an official "Eclipse IDE" release, displayed on "package" download pages and included in the installer, these rules must be followed:

All features to the package must come through the simultaneous release. That is, all Eclipse open source projects contributing features to projects must participate in the simultaneous release and follow the participation rules defined and maintained by the Eclipse Planning Council. By way of clarification, content produced by other Eclipse open source projects may be included, but only when that content is sponsored into the simultaneous release by a project that is itself participating in the process (Eclipse Jetty is an example of this). 

All bundles must be signed using the EF's certificate. Obvious exceptions will be made in cases where signing is impossible. 

We will be applying this standard to the next release and for every release thereafter. 

The means by which the simultaneous release participation rules are changed is to engage with the Eclipse Planning Council via your Eclipse Planning Council representative.

Please let me know if you have any questions or concerns.


Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

cross-project-issues-dev mailing list
To unsubscribe from this list, visit

Mickael Istria
Eclipse IDE developer, for Red Hat Developers

Back to the top