Re: [eclipse.org-planning-council] Fwd: [cross-project-issues-dev] Simul

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

To be honest, I have no strong opinion one way or the other on how JustJ is included in simrel's p2 repo. I think that if the technical reasons for leaving it out is good, then it can be left out and the planning council will hopefully approve that. I provide my comments below to try to better understand what is going on.

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com

On Mon, 1 Feb 2021 at 13:48, Ed Merks <ed.merks@xxxxxxxxx> wrote:

FYI,

I would very much prefer that the JustJ JREs not end up in any other repositories, and most certainly not in the most widely used repositories.

OK - I raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=570822 for this related issue. I don't know what it takes to resolve this issue in EPP, but I will look at it for the 2021-03 M2 release cycle this week.

 

Here is one reason why it would be better if it were not in the EPP repository to begin with:

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=569871

More fundamentally, do we really want the release train repositories to accumulate older JREs over the years, i.e., ones that may well have security issues associated with them?

I don't know why the JRE is special in this case, there is lots of stuff in old simrels with security issues.

In a related question, if an EPP package (like CPP) has the bundled JRE, should the justj update site be added to the configured update sites in the IDE? Does the Oomph created IDE do something to make the JRE update?

If the JREs are not updating on a user's machine, then I don't see that having or not having the JRE in the simrel site makes any difference.

However as https://download.eclipse.org/releases/latest is included in the update sites list, then user's will be offered new JRE with new simrel releases if JustJ is in the simrel p2 site? And further to that IIUC, if JustJ is not in simrel's p2 site, then a user will get offered to update all their IDE except the JRE on the next release cycle.

 

It's not as if I'm trying to bypass or avoid the "overhead" of being on the train.  I have to contribute EMF at -5 and Oomph at +3.  I just feel that a JRE is cross cutting and we should not accumulate old JREs in central repositories but rather should encourage the use of JREs that are either recent releases or are LTS support versions, if we ever can get those...

Keep in mind that there are a whole whack of them too, and they're really big, so which should be contributed?

The one that should be contributed is the one we are bundling in EPP to make available on eclipse.org/download.

 

  https://download.eclipse.org/justj/jres/15/updates/release/15.0.2/index.html

Regards,
Ed

On 01.02.2021 19:12, Jonah Graham wrote:

Hello Planning Council,

Can we make the below official please so that nothing about how JustJ's integration into the EPP needs to change.

Thanks

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com

---------- Forwarded message ---------
From: Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 1 Feb 2021 at 12:58
Subject: Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

At the risk of being vague and handwavy...

The requirement is that the contents of the packages come through the simultaneous release. That is, Eclipse JustJ needs to participate in the simultaneous release as participation is defined by the Planning Council. It's not clear to me whether or not "bits must be in this specific p2 repository" is an absolute requirement.

I believe that we can reasonably interpret the participation rules as permitting a project that is otherwise following the rules for participation to be absent from the specific simultaneous release repository under circumstances that make adding it particularly onerous or otherwise undesirable (that is, I believe that the fundamental principles that underlie the participation rules can be met). But I defer to the wisdom of the Eclipse Planning Council.

Wayne

On Mon, Feb 1, 2021 at 11:59 AM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

Hi Wayne,

Where does JustJ fit in here? JustJ is part of the simrel, but not part of the aggregated content on simrel? Is it still OK for EPP to consume JustJ in that way?

Thanks

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com

On Fri, 22 Jan 2021 at 10:23, 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

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council