Re: [cross-project-issues-dev] SimRel 2019-09 Repository Quality

[Ed Merks <ed.merks@xxxxxxxxx>]

Jeremie,

Comments below (though perhaps the Bugzilla is the better place for discussion).

https://bugs.eclipse.org/bugs/show_bug.cgi?id=550628

On 02.09.2019 10:52, Jeremie Miserez wrote:

Hi Ed,

 

Looking at the change at https://git.eclipse.org/r/#/c/148668/ 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.

Yes, for the package.  But note that the feature was already using SUA 2.0.1 so the license for the feature and for the produce were not consistent.

As far as I am aware, the Eclipse Scout project itself has not yet relicensed to EPL 2.0.

That's fine.  Then your other features will use whatever valid SUA they are using. 

Both the file headers and the official page at https://projects.eclipse.org/projects/technology.scout still show EPL 1.0 as the valid license.

That doesn't seem like a problem to me.  I don't think all packages should have to wait until all their content uses EPL 2.0.  The platform products for example, contain but SUA 1.1 content and SUA 2.0 content.

 

E.g. the change at https://git.eclipse.org/r/#/c/148668/1/packages/org.eclipse.epp.package.scout.feature/feature.properties has the official Scout description in the “description” field, yet modifies the “copyright” field.

I don't think that's a problem.

 

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?

No, the user will be prompted based on all content they install.  So they will be prompted for SUA 2.0 stuff just for the platform features that are included, for SUA 1.1 because of your features that haven't migrated.

That's the overall issue is that the user sees many licenses (all licenses of all features and products they are installing), and right now there are more than 3 yet only three of them are valid.

So even if the products were not fixed the way I fixed then, the user will still be prompted for accept SUA 2.0.

 

Regards,

Jeremie

-- 
Software Entwickler
BSI Business Systems Integration AG

Förrlibuckstrasse 70, CH-8005 Zürich

Telefon +41 43 501 65 93

www.bsi-software.com

 

 

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:

  https://wiki.eclipse.org/Oomph_Repository_Analyzer

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:

  https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2019-09/https___download.eclipse.org_technology_epp_packages_2019-09_M3.html
  https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2019-09/http___download.eclipse.org_releases_2019-09_201908301000.html

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:

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=537927

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

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=550628

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.

_______________________________________________
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
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev