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> 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>>: >> >> 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>> 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_ >>> >>> <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_ >>> >>> <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/>, 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> >>> 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> >> 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
