Hi, I upgraded the GEF contribution to Orbit bundles from the respective I-build: https://git.eclipse.org/r/#/c/153406/ <https://git.eclipse.org/r/#/c/153406/>.
Please let me know if that does not properly resolve the problems reported here. Regards, Alexander > Am 22.11.2019 um 17:21 schrieb Frederic Gurr > <frederic.g...@eclipse-foundation.org>: > > 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 the > next weeks to add checks and fail builds for important issues like > missing or bad licenses (and other checks that can be agreed upon to be > essential). > > Regards, > > Fred > > On 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.th...@itemis.de >>>> <mailto:karsten.th...@itemis.de <mailto:karsten.th...@itemis.de>>> 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.wat...@computer.org >>>>> <mailto:g.wat...@computer.org> >>>>> <mailto:g.wat...@computer.org <mailto:g.wat...@computer.org>>>: >>>>> >>>>> 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 >>>>> <https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements> >>>>> >>>>>> On Nov 18, 2019, at 4:57 AM, Ed Merks <ed.me...@gmail.com >>>>>> <mailto:ed.me...@gmail.com> >>>>>> <mailto:ed.me...@gmail.com <mailto:ed.me...@gmail.com>>> 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 >>>>>> <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 >>>>>> >>>>>> <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 >>>>>> >>>>>> <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=551591> >>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=551550 >>>>>> <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 >>>>>> <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 >>>>>> >>>>>> <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/ >>>>>> <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/> >>>>>> <http://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@eclipse.org >>>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>>> <mailto:cross-project-issues-dev@eclipse.org >>>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>>> To change your delivery options, retrieve your password, or >>>>>> unsubscribe from this list, visit >>>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>>>> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>>> >>>>> _______________________________________________ >>>>> cross-project-issues-dev mailing list >>>>> cross-project-issues-dev@eclipse.org >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> <mailto:cross-project-issues-dev@eclipse.org >>>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>>> To change your delivery options, retrieve your password, or >>>>> unsubscribe from this list, visit >>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>>> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>>> >>>> _______________________________________________ >>>> cross-project-issues-dev mailing list >>>> cross-project-issues-dev@eclipse.org >>>> <mailto:cross-project-issues-dev@eclipse.org> >>>> <mailto:cross-project-issues-dev@eclipse.org >>>> <mailto:cross-project-issues-dev@eclipse.org>> >>>> 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@eclipse.org >>> 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@eclipse.org >> 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 Gurr > Release Engineer | Eclipse Foundation Europe GmbH > > Annastr. 46, D-64673 Zwingenberg > Handelsregister: Darmstadt HRB 92821 > Managing Directors: Ralph Mueller, Mike Milinkovich, Gaël Blondelle > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
