|
Greg,
Yes, the Planning Council has been discussing stronger
enforcement. One major problem is that removing one project can
have a cascade effect on others, and this effect is not well
understood; we don't have a Report on the dependency tree of the
contributions. But in the end, only leaf projects could be easily
removed. I know for example that if USSSDK is removed, MPC and
Oomph use that. If DTP is removed, parts of EMF (ODA) extend that
framework, and so on; this feature of EMF could be excluded. As
such, tracking the impact of removals is currently a
time-consuming challenge.
Yes, the requirements page could be more clear and the "new
reporting process" of course ought to align with the requirements
but what I've done so far is intended to align with the existing
requirements. And I've focused "error reporting" problems
primarily on things the user will notice immediately when she
installs. Using a proper license is a basic requirement for any
project distributing Eclipse content, so no license or a bad copy
of the license is just never acceptable. As for Orbit
"requirements," it's not a requirement to use a specific version
of Orbit, but if we did all use a specific version we'd have fewer
duplicates (a very nice to have and avoids what sometimes leads to
a major runtime wiring problem), and we'd have more recently
signed content (no that Orbit has addressed some outliers).
Karsten,
In the long term, we'd of course like more validation to be doing
during the commit of new content. But some folks (I know who you
are), are pointing a dynamically changing content...
Regards,
Ed
On 18.11.2019 15:30, Greg Watson wrote:
Voluntary is good up to a point, and by all means give projects
the chance to fix the issues before taking action. However if
projects are not complying, then at some point you need to say
that the quality of the release is more important. Now that the
release cycle is more frequent, there could be a limit of N
releases (e.g. N=2) for non-conforming projects, then they are
excluded.
Regards,
Greg
I don’t
think that excluding these projects would be a wise
choice. Then immediately a large set of project had to
leave SimRel, and clients are used to find many of them
in the SimRel.
Of course the projects that are failing to
fulfil the required constraints should know that they
have to do something to do. For me the right point
would be the SimRel aggregation validation build. If
there could be more checks performed there the
contributing projects will immediately recognise a
task when they can’t get a successful build when
contributing to SimRel. These restrictions could be
added one by one, starting with most urgent ones, e.g.
invalid license, missing signing.
~Karsten
Hi Ed,
Thanks for your effort to try to
improve the quality of the simrel. I was
wondering why we don’t simply exclude all
non conforming projects from the simrel
until these issues have been corrected? This
would seem to be particularly important for
projects contributing content that is signed
with expired certificates. Also, as far as I
can see, the Simultaneous Release
Requirements page [1] does not go to the
level of detail that your email is
suggesting, so it would be good to update
this with more specific requirements, such
as with version of Orbit projects should be
building with. Ideally however, these
requirements would be checked automatically
and the project excluded if non conforming.
Regards,
Greg
[1] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements
SimRel Participants,
While we're making
progress on improving the state of
the SimRel repo for 2019-12,
without the active involvement of
the ~80 teams contributing
content, we're still going to fall
far short of an acceptable quality
benchmark.
Many projects simply
need to do a new build to use the
proper and correct version of SUA
2.0 from CBI and to
use the latest Orbit
dependencies.
Roland Grunberg has been
kind enough to publish a new Orbit
I-build to ensure that there are
no bundles signed with expired
root certificates:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=552251
The Orbit dependencies
that you contribute to the train
should come from there, and not
some antiquated older version.
You should also look closely at
whether your contributed or Orbit
dependencies align those
contributed by other projects.
Currently 55 bundles are
contributed as duplicates which is
something we ought to avoid. But
at this point, duplicates is the
least of my concern. Just don't
contribute old versions of
com.google.inject.assistedinject_3.0.0.v201402270930
and
org.antlr.runtime_3.0.0.v200803061811.
That mean the ATL teams
needs to pay attention
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.m2m.atl.dsls_4.1.0.v201909021645.html#osgi.bundle;_org.antlr.runtime_[3.0.0,3.1.0)
Also the GEF team:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.gef.mvc.fx.ui_5.1.1.201910161621.html#java.package;_com.google.inject.assistedinject_[1.3.0,1.4.0)
These dependency ranges
will force the old problematic
version.
What concerns me most is
that some teams are completely
unresponsive:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=551591
https://bugs.eclipse.org/bugs/show_bug.cgi?id=551550
So it heartens me to
see others who have taken active
steps:
https://github.com/eclipse/eclipse-collections/issues/763
Out of respect for all
those many active participants who
work tirelessly to contribute high
quality results, please consider
that your inaction reflects poorly
on all of us. In the end, the
user doesn't care or know where
things come from, they are faced
with dialogs displaying many
"duplicate" licenses, they see
dialogs asking them to accept
expired (root) certificates, and
dialogs to accept the installation
of unsigned content. It just
doesn't give the user a warm fuzzy
feeling that they're about to
install something really great and
that undermines the effort of
hundreds of us who are working
hard to give a great first
impression and well as a lasting
good impression.
This is is the future
state for M3 if no further action
is taken:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index.html
That state is a result
of your contributions:
https://download.eclipse.org/oomph/archive/simrel/
I believe there are a
significant number of
contributions that have simply
died long ago but their input
lingers on in a limbo zombie
state. Those will need to be
removed... And when one sees
contributions coming from archive.eclipse.org,
or with neon, oxygen, and photon
in the name, or ending with
"snapshots", you know that's
likely questionable and is likely
old crap or totally unstable in
terms of content.
Regards,
Ed
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options,
retrieve your password, or 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 change your delivery options, retrieve your
password, or 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 change your delivery options, retrieve your password,
or 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 change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
