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.me...@gmail.com> 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 ™ but good that it's okay with ™ > 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@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
