[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse.org-planning-council] Fwd: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages
|
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.
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?
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?
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
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
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
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