Hi, ATL's dependency on ANTLR 3.0.0 is tracked in https://bugs.eclipse.org/bugs/show_bug.cgi?id=553275
Kind regards, Dennis Wagelaar On Tue, Nov 26, 2019 at 1:25 PM Alexander Nyßen <nys...@itemis.com> wrote: > Hi, > > I upgraded the GEF contribution to Orbit bundles from the respective > I-build: 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 <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 <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 > > On Nov 18, 2019, at 4:57 AM, Ed Merks <ed.me...@gmail.com > <mailto:ed.me...@gmail.com <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 > > 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@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org > <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 > <mailto:cross-project-issues-dev@eclipse.org > <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 > <mailto:cross-project-issues-dev@eclipse.org > <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 > 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
