[CANCEL][VOTE] Release apache-calcite-1.19.0 (release candidate 0)

[Kevin Risden <kr...@apache.org>]

RC 0 was cancelled due to CALCITE-2925
<https://issues.apache.org/jira/browse/CALCITE-2925>

Kevin Risden


On Mon, Mar 18, 2019 at 7:04 PM Julian Hyde <jh...@apache.org> wrote:

> 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
> <kr...@apache.org> 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 <an...@sereda.cc> 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 <
> >> sitnikov.vladimir@gmail.com> 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
> >>>
> >>
>
>