Kevin, I think you should send a [CANCEL] message to formally cancel the vote for RC 0.
Julian > On Mar 18, 2019, at 10:39 AM, Kevin Risden <[email protected]> wrote: > > Vote on RC1. The mvnw jar file was removed. Including the mvnw jar was a > change from previous releases. Other binary files have been in previous > releases since they are needed to build/test Calcite. > > Kevin Risden > > > On Mon, Mar 18, 2019 at 11:58 AM Andrei Sereda <[email protected]> wrote: > >> Hello, >> >> Can one vote on RC 1 (separate thread) or should we wait on decision >> wherever having jar files in calcite source distribution is acceptable ? >> >> On Fri, Mar 15, 2019 at 4:08 PM Vladimir Sitnikov < >> [email protected]> wrote: >> >>> Julian> Lastly, this .jar file is non-essential. The release builds >>> just fine without it. >>> >>> The use of consistent build tool versions would reduce risks. >>> For instance: Maven 3.6.1-SNAPSHOT might happen to build Calcite "just >>> fine" yet it could silently corrupt something. >>> Then ./mvnw does not verify download integrity, so it makes >>> build/release less secure. >>> >>> Why take those risks? >>> How can I validate calcite.jar artifacts that are uploaded to Maven >>> repository? Which tool could I use to validate that jars match the >>> expected ones? >>> Can I vote for source artifacts only and explicitly veto binary jars >>> on a basis of "I can't validate wha's inside"? >>> >>> Even though Maven does not support wrapper natively, the case for >>> wrapper would be even more important when we use Gradle. >>> >>> I see a couple of options: >>> A) Include maven-wrapper.jar, and put its expected SHA256 side by >>> side. We don't update the file often, so "IP and/or tampering" could >>> be checked by verifying SHA for the jar file. >>> >>> B) We could include maven-wrapper in a source form and build it during >>> the very first mvnw call. All the *.java files for maven-wrapper sum >>> up to 70KiB which is just tiny. >>> A single JdbcTest.jar is 350KiB. >>> >>> Any thoughts? >>> ^^ The question above is quite real and I guess the answer would be >>> pretty much reused for Gradle-based build. >>> >>> Julian> Since we have created them, and they are available nowhere else, >>> they >>> Julian> belong in the source release. >>> >>> I don't think we created fontawesome-webfont.ttf, did we? >>> Technically speaking, calcite/site/fonts is 500+KiB which does look >>> like binary files. >>> >>> Julian> Code is different. The textual source is editable, but the object >>> Julian> files (in this case the .class files in the .jar) are not. >>> >>> As you know, "TrueType systems include a virtual machine that >>> executes programs inside the font", so *.ttf is an object file. >>> There are CVEs for TTF processing. >>> >>> Even though it might sound like a stretch, I don't quite buy "having >>> consistent build system is not important" kind of conclusions. >>> >>> Vladimir >>> >>
