Can we not litigate policy here, please? We are PMC members, this is a release vote, we need to follow policy.
> On Apr 8, 2021, at 12:32 PM, Vladimir Sitnikov <[email protected]> > wrote: > > Julian>(Technically there are no binary releases, just artifacts. > > I stay corrected. The better term is "source package" and "compiled/binary > package" which are both parts of the release. > > Julian>Apache policy, as I understand it, does allow images in source > releases > > I believe the policy is not mathematically defined. > If you have a link that states "binary files must not be in source package" > please let me know. > Of course, I did not analyze all the tickets in LEGAL, however, LEGAL-288 > does not forbid releasing gradle-wrapper.jar as a part of source package. > > --- > > For instance, Apache JMeter is a standalone desktop application, and you > can't really build > a workable application if all the icons and images were removed from the > source package. > The app would start, however, it would be very hard to use for the majority > of the users. > > To my understanding, the intention is that the build artifacts should not > be the primary part of the release and that there always should be a way to > build the resulting binaries. > However, to my best knowledge, excluding binary files from the source > package is not really feasible. > For instance, images might serve an important part in the documentation and > in the application user interface. > > Julian>Not sure about .min.js, but it isn’t binary > > I believe the most important bit is the ability for humans to look inside > and analyze. > Of course, .min.js looks like a text file, however, it is written in such a > way that humans can't really tell what the code is doing. > Would it remove all the files in my filesystem if I run it? I don't know. I > need a beautifier and IDE to analyze the behavior of the minified > javascript. > In that sense, .min.js is more or less the same as jar file, except jar > file might be even better since most of the times class and variable names > are not obfuscated in Java. > > Julian>It is also reasonable that when I browse the source in GitHub I > should see the same LICENSE file that will be in the source release > > That would imply every third-party dependency update would trigger an > update to the LICENSE file which means: > 1) Every contributor that updates a dependency would bump into CI failure > that reads "oh, you forgot updating LICENSE file" which will be annoying. > 2) I test different third-party library versions. That might induce > LICENSE-related failures when I update the dependency version without > updating the version in the LICENSE. Do you mean I should always edit > LICENSE file when editing dependency versions? That won't work. > 3) If we validate LICENSE contents only during the release, then release > managers might bump into the weird "oh, LICENSE file is out of date". > > That is why I believe, the way it works now is the least evil, however, you > are welcome to improve it. > The current implementation allows us to have a single base copy of LICENSE > file, and it is used to build all the different licenses. > For instance, calcite-avatica/shaded/core uses the same base LICENSE file > and it adds the shaded third-party references there. > > If we put "the expected source artifact LICENSE" to the root of the > repository, then: > a) We would have to put "base license file for shaded artifacts" somewhere > else > b) People might assume that the LICENSE file covers all the entries in the > Git repository. > > For instance, Calcite repository has site/fonts/ which have a license that > is incompatible with ASF source artifact restrictions. > If you put "source artifact license" to the root of apache/calcite > repository, people might assume that everything in apache/calcite is AL2 > compatible. > Here's what I mean: > https://github.com/apache/calcite/blob/8581f0a3fe9a4f079cb4d36f02121ae22118714c/release/build.gradle.kts#L145-L157 > > Well, of course, you could just remove site/fonts from the Git repository, > whoever, that would paint us to a corner if we ever add a similar > dependency. > > Vladimir
