Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Making SimRel Great Again
  • From: Frederic Gurr <frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 22 Nov 2019 17:21:45 +0100
  • Autocrypt: addr=frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx; prefer-encrypt=mutual; keydata= mQINBFeN7eABEADU1DWW0e6X3UBsKwwN8+EtviRWuEcUTJBCspUfyhS+LnfzB944GN3h32uT 5ClPPc8bUIuipCfW/2BlkP9EhK3hfiD/LwDv2tS9K5nFsi+SawjYLRvQG+7d21Pe3LVUWpv3 K6OXuEZvdf+e/ljkhtATt0OmwbvxN3i9vzJHAYiFUTNgTO27ui2sqOI9uDXXTP7L0OdMbjun lsBMKMzd8BZLvsqbBvUbWihXqDvCgnPLbJw6VWrLjlfvWXQ9qIQQemzyG8tlII49LpX3gwH0 /jS6HVgSh52L7xohIivkJa4JkpPhGi8srAfxptQ3Kl2udhQkM8wswXsbIT89gsbJflsbYfDt uZLfjA9U+9UyrlgF5mYwpgGIawvuyi+YcJy8OzJWLnGq7jayJRT85udCiyDkCTDXxu0jSSjk By+NKG2T/dO2R96RbR2PuSzERhyMSCMAZOxoqCYf3mD9oeiNB9flwnxJpHKxuGBkG8zaQE6x sw4f4ZS88OCh854t33JKrlHXB9UTlMRHO9jj4cVKzFrEFZlUdIuu2WuDxYnFsI4tZAabn8V1 mFOkwz8ir/3IpM7GQbbq3ierJ5rYd87rkYroeNAOmUZW/7cM/5u7bOEzb+xlpn9OqQ63nAmN M2vMZEUIfzU/HhkhM3ItjWf74Fr4I9jseIvkrF3CrMyU1wPcJwARAQABtDRGcmVkZXJpYyBH dXJyIDxmcmVkZXJpYy5ndXJyQGVjbGlwc2UtZm91bmRhdGlvbi5vcmc+iQI9BBMBCAAnBQJZ 7dQrAhsjBQkJZgGABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBCQq+fyYxnhN40P/jrs 1JqFahe2AV5P14GXIB0dWTt+pmiTk2r31hhPIfKz5/PiANzVc7yqRbjgNA8ZcH5Fjz94AFEv aza8Rapce4GFFwYVlL4+jtDhEMpWX6ZFTd1Ok25x7HhMpjHodk+Bc2fzxejKZ2oS+cApPTeW sS2WwLL+MVk8nLSZTgQYe5Bu0Vepoiql8x12BAPWNQfv1D3Mef1c4ttvN1bg+NAMAoovVa88 FdIlzurw2zIwcStOS0YoD44P+21TKe3TYYnbtLwz+bSH0N2WRHpRJ8GUKdYt9dgdRBnZnijd CV0qK0ksA5Zf9oMr/na+PcSuQ7/674RIvhlFx3bQ/qmTYhKq2GDJImRsXS0jfQBZ4RJUwYdh I7wnnD7NS0U5HypohY5Zv833TnawJVqzXhZwSu2TjK7S6YsgYhCQRgvTrhrXNy/1c6DtsEfx qP3AqCRoDGQJNO5rZKh6NFpppZnU1n+hDEHCR1SJntgiUV7GhHy+V9ECk/AZJA+wOoWdNamh fcobFZ6+q+jWo6a6UQNt30c14knKZbOx2W20jb0W0nIlFjOcvAJtEhwWilJr9StZDi17Sa4z eWmKQtGS/FguZ0O881u1TsH8c1+J84SO/EtSbdbaEze9AG2rWRYb0BTYFF+r7X8M2RVjnKF/ iiwAW/+mHRt+/VnFR0bC7Ry62CI5LMzKuQINBFeN7eABEAC9vYYVrwmSpm/J7FbR2M5GCC9C 7veXd7VSQ0TEnq98v8pje7rd8gakUFkMyqxEb06354aRDJIsyHZmSJCKhAcRPrzwkrVXYTMT GS/TC2Vrk0x88F1nWQm5h2eNLvIybT0JYd728P/5fSh208T2BCgvgL9w3e2/z5tH3IHW490B Wm5xji2cGCaqkeQw7hzxjCXp/k24EcZ1EzH0x4mTHmP3s7WAKSb6bx8+38wKsrYNhpkw847R 3MZadmitMqvOJ+em8K+67U+NDaergoRUL3oSgNYx67mm9xXBYLjiSAx1e+yhzjLfC+WziaXq CELFpdldR5Ds1Fe+BeeeK7v7EhmDi+h/Guh2KDWRbbafDzAc8EG5Ifuf/5g4NI1kEiK49c3L xIzvT9dzujBPFvl9We7Hd+jp/rZ7YSsOHEpXrcRUMuSFpQUfsTsp6fYxeFQRy/38hO1Ye6sp PwfcRTJEi9reMJbA+bR4Mk2LWsqlHuZzHMA5chS7XbVCngcEdlu1vTMlycYuKb+wAg9vrEbb cWHbeUffZx2+fy4+lLUygWRJmGAY5MdXOSn31tL0Ou+rF+moNZDo3EgjSZ7GqIKOzpptCFoh BqJQ/fgBIBIfAfKf5ThvEZ8pOvFGA61YT6MJHmUK4JbZT6mrf8a2s4yhQKjlNo/FodTy5SyQ TQFntR+DBwARAQABiQIlBBgBCAAPBQJXje3gAhsMBQkJZgGAAAoJEBCQq+fyYxnhQa4P/jhB N9NXFncGD2TzaLnSsBQNpvJp9wRK70Ea3mwMxbAayOiIV7CF1Cjp/L0aCgLnO8nl0yZMBbkM Ntot0qZ5M9nZZYxKyrbZS6ElWoHLKJHQNfazW5Jc5/8RBJvxtWbR/RfwCzLEYFI0hUY1UsVB hsq4KCNKBt6eWqoFaSM+hzWAc1rOYlDKswkA+bqJiPifYatWcrjolmuAMNUWAuWKgRtVbcCZ IqHkDyvvc0LkV4nhCHGbqLE6+MoaLb/JZMChvPN+tl+sHxxQJcagJ5U15dgSp+XYDIN2fCw+ ViRTr/2nKsUh/WKfyXnXq1PwJoVMGUFOULHaLBmqTfoubPQRZXWhcKzU68CdvLykyDKVdrQL SI0acgK8ZOZwRIZvVdjDM2iR5PtoX2RtAoU7blkjHTrL9C23yesvM1woFStaCt6DMwMJ1n0U oODmwf8/d65AM4mLjHd4eQn8fqnfG66y9RGnO+uYohDm22v6jxbhC9HeUf7EB2Sz+t6zllEM hkGvKr7W0yW9aXuv1ClyhVLypzh5g1fKPf29TGLT1pFecyF19Hxz5BHP1eH7nEVj/OsF9hmt RHZstOSALb4H+IXZrc7x2Q2okEcWui03fQJrKiL/gtyyU4aH62nI5VOGu5zoa669m0cbBofS kr0KPtEgdm15rQ8tiPH8bKZLHQ5e/2Li
  • Delivered-to: cross-project-issues-dev@xxxxxxxxxxx
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • Openpgp: preference=signencrypt
  • Organization: Eclipse Foundation
  • User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0


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



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.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]
>>>>> 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:
>>>>> 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
>>>>> and
>>>>> org.antlr.runtime_3.0.0.v200803061811.
>>>>> That mean the ATL teams needs to pay attention
>>>>> Also the GEF team:
>>>>> These dependency ranges will force the old problematic version.
>>>>> What concerns me most is that some teams are completely unresponsive:
>>>>> So it heartens me to see  others who have taken active steps:
>>>>> 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:
>>>>> That state is a result of your contributions:
>>>>> 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
>>>>> <>, 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
>>>> _______________________________________________
>>>> 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
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> 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

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

Back to the top