Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] ACTION REQUIRED: p2 Repository Quality Problems

Ed, typically platform committer self-commit their work. As we are in the release freeze additional approval is required which has been given by Sravan and me.

Ed Merks <ed.merks@xxxxxxxxx> schrieb am Fr., 30. Aug. 2019, 10:07:

The discussion seem to have gotten side-tracked around the already-fixed problem:

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

Should I review and submit this Gerrit patch myself or will someone else do that? I'm never quite sure of the appropriate process here...

The import question that's still outstanding is the following:

  How will we update to the correct license and ensure that all feature versions are incremented at least minimally?


On 29.08.2019 17:27, Ed Merks wrote:

Folks,

I've been working on a tool that generates a quality report for p2 repositories.  The initial prototype is now complete.  I've documented it here:

  https://wiki.eclipse.org/Oomph_Repository_Analyzer

Things are in pretty rough shape overall. 

Given that the Platform team is among the most skilled at managing their builds properly, I though it would be best to begin cleaning shop ourselves before approaching the broader release train participants (which unfortunately I'm quite sure will be like trying to herd cats).

I now generate the following page for the Platform's current IBuilds:

  https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.13-I-builds/index.html

My biggest concern is the licenses, because quite frankly, that's a disaster area.  As Vikas has already observed, this results in what appear to be duplicate license prompts:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=549523
https://bugs.eclipse.org/bugs/attachment.cgi?id=279381

This is embarrassing to Eclipse and annoying to the users.  Only collectively as a group can we can fix this.

There are two major causes for this problem with regard to the Platform. 

The first cause is that all the Platform's products have in some way messed up the trademark symbol.  I've opened this Bugzilla and included a Gerrit commit with the fixes:

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

(Too bad Tycho doesn't like &trade; but good that it's okay with &#8482; because I think using the actual unicode symbol is just begging for someone to corrupt it again.)

The second cause stems from the fact that CBI produced two bad variants of SUA 2.0.  So you'll see that the CBI license composite does not contain a valid SUA 2.0.

  https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/cbi/updates/license/index.html

The valid one is located in this repo:

  http://download.eclipse.org/cbi/updates/license/2.0.2-SNAPSHOT

But it's been almost a year ago that it was fixed and then it stalled:

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

So let's just compose that into the composite to solve the problem, right? 

That unfortunately is also a problem, because the license is copied into the feature's artifact and all the platform's features look like this:

<feature
      id="org.eclipse.jdt"
      label="%featureName"
      version="3.18.100.qualifier"
      provider-name="%providerName"
      license-feature="org.eclipse.license"
      license-feature-version="0.0.0">

I.e., they in no way restrict the version, so if the version resolves to a different version (from using an updated composite), the IU metadata will be different and the actual artifacts will be different too. You can look at this artifact to confirm that this is the case:

  https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.13-I-builds/http___download.eclipse.org_eclipse_updates_4.13-I-builds_I20190828-1800/org.eclipse.jdt.feature.jar_3.18.100.v20190828-1800.html

I.e., the feature.properties in this artifact has the license but that information is not present in the Git version of feature.properties.  Also the license.html itself is copied into the artifact during the build.

So the question is how are we going to fix this in a way that ensures we produce new IU versions for all features?  That sounds like a lot of work!

Also of concern is unsigned content, but only org.eclipse.jdt.core.compiler.batch falls in that category, so that seems easy to address.  Hopefully someone will.

Finally there are many missing pack200 artifacts. Although this isn't a huge problem---it doesn't break anything---it does result in increased network traffic.  The pack200 versions are generally from 50% to 30% the size of the original *.jar, so jdt.core at 6.6M just by itself could save quite some traffic. 

Why are are so so many pack200 artifacts missing?  Is this easy for us to fix?

Regards,
Ed







_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Back to the top