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>

Attachment: 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

Reply via email to