Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] SimRel 2019-09 Repository Quality

Hi Ed,


Looking at the change at for org.eclipse.epp.package.scout.feature, it seems like this actively changes the license for packages from EPL 1.0 to EPL 2.0. As far as I am aware, the Eclipse Scout project itself has not yet relicensed to EPL 2.0. Both the file headers and the official page at still show EPL 1.0 as the valid license.


E.g. the change at has the official Scout description in the “description” field, yet modifies the “copyright” field.


Is my understanding correct that this will result in users not seeing the appropriate license (EPL 1.0) prompts when installing the Scout EPP package?




Software Entwickler
BSI Business Systems Integration AG

Förrlibuckstrasse 70, CH-8005 Zürich

Telefon +41 43 501 65 93



From: cross-project-issues-dev-bounces@xxxxxxxxxxx <cross-project-issues-dev-bounces@xxxxxxxxxxx> On Behalf Of Ed Merks
Sent: Monday, September 2, 2019 9:56 AM
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Subject: [cross-project-issues-dev] SimRel 2019-09 Repository Quality


I've been working on an application for analyzing p2 repository quality, primarily with a focus on the release train repository.

It generates a report with detailed information about the contents and quality of one or more repositories as documented here:

My primary concern at this point is to eliminate invalid licenses so that users aren't prompted to approve multiple slightly different variants of the same license. My secondary concern is to eliminate unsigned content; this too is something for which the user is prompted. Both of these things present to the outside world an unprofessional impression of our releng processes. A nice-to-have would be if everyone provided pack200 artifacts, where appropriate, because this will speed up the installation/update process for our community (and it is a requirement for being on the train). Look at the last section of the report for these details.

The following are the reports for 2019-09 M3:

The primary source of bad licenses at this point is unfortunately the central license repository itself. This issue will be addressed by the following Bugzilla:

To address the problems in the EPP repo, I've open the following Bugzilla with a Gerrit commit to fix all the problems:

That in combination with the fix to the central license repository will make it clean; I've verified that against the Gerrit build results.

Unfortunately the release train repo is is rough shape and I will not personally (like I did for the platform EPP) be able to fix all these problems.

If you look at the report yourself (and please do), and your features or products are not in one of the valid groups (and not in the blue circled group which will be fixed when the central license repo is fixed and you create a new build using that fixed repo), then you need to take action:

Also please look at the unsigned content:

Please fix your build to sign the content; it's a requirement for being on the train. Looking at some of the build dates though, I'm concerned that folks aren't really actively participating.

Thanks in advanced for helping to improve the quality of our releases.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Back to the top