Hi,
Please let me know if that does not properly resolve the problems reported here.
Regards,
Alexander
Hi,Sorry, for the late reply. +1 for more validation as part of the SimRel(Gerrit) build. I'm planning to set aside some time for this over thenext weeks to add checks and fail builds for important issues likemissing or bad licenses (and other checks that can be agreed upon to beessential).Regards,FredOn 18.11.19 17:20, Ed Merks wrote: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
On Nov 18, 2019, at 9:18 AM, Karsten Thoms <karsten.thoms@xxxxxxxxx
<mailto:karsten.thoms@xxxxxxxxx>> wrote:
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
Am 18.11.2019 um 15:02 schrieb Greg Watson <g.watson@xxxxxxxxxxxx
<mailto:g.watson@xxxxxxxxxxxx>>:
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
On Nov 18, 2019, at 4:57 AM, Ed Merks <ed.merks@xxxxxxxxx
<mailto:ed.merks@xxxxxxxxx>> wrote:
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
<http://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
<mailto: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
<mailto: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
<mailto: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
-- Frederic GurrRelease Engineer | Eclipse Foundation Europe GmbHAnnastr. 46, D-64673 ZwingenbergHandelsregister: Darmstadt HRB 92821Managing Directors: Ralph Mueller, Mike Milinkovich, Gaël Blondelle_______________________________________________cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
