You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Kevin Risden <kr...@apache.org> on 2019/03/14 17:08:20 UTC
[VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Hi all,
I have created a build for Apache Calcite 1.19.0, release candidate 0.
Thanks to everyone who has contributed to this release.
You can read the release notes here:
https://github.com/apache/calcite/blob/branch-1.19/site/_docs/history.md
The commit to be voted upon:
https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=a08c36fb0284ad121040c336e7d75001019f3495
Its hash is a08c36fb0284ad121040c336e7d75001019f3495.
The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.19.0-rc0/
The hashes of the artifacts are as follows:
src.tar.gz.sha256
a04bfb1bac830e57475dffdbf5f0c3a797c358460d240f6203c929bac61b47ae
A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1053/
Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/krisden.asc
Please vote on releasing this package as Apache Calcite 1.19.0.
The vote is open for the next 72 hours and passes if a majority of
at least three +1 PMC votes are cast.
[ ] +1 Release this package as Apache Calcite 1.19.0
[ ] 0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...
Here is my vote:
+1 (binding)
Kevin Risden
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Julian Hyde <jh...@gmail.com>.
If I was release manager for 1.18, it’s possible that I used ‘mvn’ rather than ‘./mvnw’. I don’t recall. If so, my bad, I should have updated the release instructions.
Julian
On Mar 14, 2019, at 7:22 PM, Kevin Risden <kr...@apache.org> wrote:
>>
>> maven-wrapper.jar is a binary file, and we cannot have binary files in
>> source distributions. (Note that ./mvnw can bootstrap just fine without it.
>> Also note that it is not checked into git — I guess it is created during
>> the release build process.)
>>
>
> Hmmm that is interesting. ./mvnw downloads the
> .mvn/wrapper/maven-wrapper.jar file. The release steps say to use ./mvnw
> (ie: ./mvnw -DskipTests -Papache-release release:perform 2>&1 | tee
> /tmp/perform.log) so not sure if there is something I need to do
> differently or needs to be figured out to ensure the .mvn directory is not
> included in the source distribution.
>
> Kevin Risden
>
>
>> On Thu, Mar 14, 2019 at 8:56 PM Julian Hyde <jh...@apache.org> wrote:
>>
>> PS Huge thank you to Kevin for being release manager. This has been one of
>> our most complex releases, and I know that Kevin has put in a massive
>> effort to get the release this far. I hope the process is over soon!
>>
>>> On Mar 14, 2019, at 5:51 PM, Julian Hyde <jh...@apache.org> wrote:
>>>
>>> -1 due to .mvn/wrapper/maven-wrapper.jar
>>>
>>> maven-wrapper.jar is a binary file, and we cannot have binary files in
>> source distributions. (Note that ./mvnw can bootstrap just fine without it.
>> Also note that it is not checked into git — I guess it is created during
>> the release build process.)
>>>
>>> Everything else was fine. Checked hashes, KEYS, LICENSE, NOTICE, README;
>> checked that contents of tar match git; compiled and ran tests using JDK 11
>> on Ubuntu linux.
>>>
>>> Julian
>>>
>>>
>>>> On Mar 14, 2019, at 10:30 AM, Vladimir Sitnikov <
>> sitnikov.vladimir@gmail.com> wrote:
>>>>
>>>> +1 (binding)
>>>>
>>>> Checksum matches, the code compiles.
>>>> Release notes look ok.
>>>>
>>>> Thanks, Kevin
>>>>
>>>> Vladimir
>>>
>>
>>
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Kevin Risden <kr...@apache.org>.
>
> maven-wrapper.jar is a binary file, and we cannot have binary files in
> source distributions. (Note that ./mvnw can bootstrap just fine without it.
> Also note that it is not checked into git — I guess it is created during
> the release build process.)
>
Hmmm that is interesting. ./mvnw downloads the
.mvn/wrapper/maven-wrapper.jar file. The release steps say to use ./mvnw
(ie: ./mvnw -DskipTests -Papache-release release:perform 2>&1 | tee
/tmp/perform.log) so not sure if there is something I need to do
differently or needs to be figured out to ensure the .mvn directory is not
included in the source distribution.
Kevin Risden
On Thu, Mar 14, 2019 at 8:56 PM Julian Hyde <jh...@apache.org> wrote:
> PS Huge thank you to Kevin for being release manager. This has been one of
> our most complex releases, and I know that Kevin has put in a massive
> effort to get the release this far. I hope the process is over soon!
>
> > On Mar 14, 2019, at 5:51 PM, Julian Hyde <jh...@apache.org> wrote:
> >
> > -1 due to .mvn/wrapper/maven-wrapper.jar
> >
> > maven-wrapper.jar is a binary file, and we cannot have binary files in
> source distributions. (Note that ./mvnw can bootstrap just fine without it.
> Also note that it is not checked into git — I guess it is created during
> the release build process.)
> >
> > Everything else was fine. Checked hashes, KEYS, LICENSE, NOTICE, README;
> checked that contents of tar match git; compiled and ran tests using JDK 11
> on Ubuntu linux.
> >
> > Julian
> >
> >
> >> On Mar 14, 2019, at 10:30 AM, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
> >>
> >> +1 (binding)
> >>
> >> Checksum matches, the code compiles.
> >> Release notes look ok.
> >>
> >> Thanks, Kevin
> >>
> >> Vladimir
> >
>
>
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Julian Hyde <jh...@apache.org>.
PS Huge thank you to Kevin for being release manager. This has been one of our most complex releases, and I know that Kevin has put in a massive effort to get the release this far. I hope the process is over soon!
> On Mar 14, 2019, at 5:51 PM, Julian Hyde <jh...@apache.org> wrote:
>
> -1 due to .mvn/wrapper/maven-wrapper.jar
>
> maven-wrapper.jar is a binary file, and we cannot have binary files in source distributions. (Note that ./mvnw can bootstrap just fine without it. Also note that it is not checked into git — I guess it is created during the release build process.)
>
> Everything else was fine. Checked hashes, KEYS, LICENSE, NOTICE, README; checked that contents of tar match git; compiled and ran tests using JDK 11 on Ubuntu linux.
>
> Julian
>
>
>> On Mar 14, 2019, at 10:30 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>>
>> +1 (binding)
>>
>> Checksum matches, the code compiles.
>> Release notes look ok.
>>
>> Thanks, Kevin
>>
>> Vladimir
>
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Kevin Risden <kr...@apache.org>.
I am canceling the vote due to
https://issues.apache.org/jira/browse/CALCITE-2925
Thanks to all who voted. I should have a new RC out shortly.
Kevin Risden
On Fri, Mar 15, 2019 at 9:53 AM Kevin Risden <kr...@apache.org> wrote:
> I think the difference is that the files you listed Vladimir are needed to
> rebuild (compile and test) the project. maven-wrapper.jar is not needed
> since mvnw will download it as needed.
>
> Kevin Risden
>
>
> On Fri, Mar 15, 2019 at 3:07 AM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
>> Julian> maven-wrapper.jar is a binary file, and we cannot have binary
>> files in source distributions.
>>
>> Hey, Julian, that is a great finding!
>> Can you please clarify if the following binary files count towards -1 as
>> well?
>>
>> site/img/pie-chart.png
>> site/img/cake.jpg
>> site/img/pb-calcite-140.png
>> site/img/pb-calcite-240.png
>> site/img/powered-by.png
>> site/img/window-types.png
>> site/img/logo.png
>> site/img/feather.png
>> site/fonts/fontawesome-webfont.ttf
>> site/fonts/fontawesome-webfont.woff
>> site/fonts/fontawesome-webfont.eot
>> file/src/test/resources/sales-csv/EMPS.csv.gz
>> example/csv/src/test/resources/sales/EMPS.csv.gz
>>
>> Vladimir
>>
>
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Kevin Risden <kr...@apache.org>.
I think the difference is that the files you listed Vladimir are needed to
rebuild (compile and test) the project. maven-wrapper.jar is not needed
since mvnw will download it as needed.
Kevin Risden
On Fri, Mar 15, 2019 at 3:07 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Julian> maven-wrapper.jar is a binary file, and we cannot have binary
> files in source distributions.
>
> Hey, Julian, that is a great finding!
> Can you please clarify if the following binary files count towards -1 as
> well?
>
> site/img/pie-chart.png
> site/img/cake.jpg
> site/img/pb-calcite-140.png
> site/img/pb-calcite-240.png
> site/img/powered-by.png
> site/img/window-types.png
> site/img/logo.png
> site/img/feather.png
> site/fonts/fontawesome-webfont.ttf
> site/fonts/fontawesome-webfont.woff
> site/fonts/fontawesome-webfont.eot
> file/src/test/resources/sales-csv/EMPS.csv.gz
> example/csv/src/test/resources/sales/EMPS.csv.gz
>
> Vladimir
>
[CANCEL][VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by 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
> >>>
> >>
>
>
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Julian Hyde <jh...@apache.org>.
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
>>>
>>
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Kevin Risden <kr...@apache.org>.
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
> >
>
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Andrei Sereda <an...@sereda.cc>.
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
>
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Vladimir Sitnikov <si...@gmail.com>.
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
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Julian Hyde <jh...@apache.org>.
First of all Vladimir, please cut out the sarcasm. It's not constructive.
We can't claim that some of the files in our release are not Calcite
sources. There is no other definition of "Calcite source code" than
what we include in a release. So, everything in that tar file is by
definition "Calcite source code".
There are some kinds of files, such as .jpeg, which do not exist in
any form other than binary. One creates them by editing them directly.
Since we have created them, and they are available nowhere else, they
belong in the source release.
There is a case to be made that we should omit files like EMPS.csv.gz.
If you think it's important, go ahead and make that case.
Code is different. The textual source is editable, but the object
files (in this case the .class files in the .jar) are not. The open
source definition makes a big deal about distributing source code,
because it is not practical to improve on someone's work if your only
means to change it is to edit their object files.
Apache release policy bans object files because they are difficult to
audit (for mischief such as IP infringement or malware). It's not
really possible to vote on a release that contains object files.
Lastly, this .jar file is non-essential. The release builds just fine
without it.
Julian
On Fri, Mar 15, 2019 at 7:24 AM Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> Julian> The Release Policy [1] states that for a (compiled) artifact
> the source code has to be released alongside.
>
> maven-wrapper.jar has nothing to do with Calcite's source codes, so
> maven-wrapper.jar is not "a compiled version of the source", so [1]
> does not apply here.
> It is the very same thing as "binary font file".
>
> I don't see why the policy would allow *.ttf and forbid *.jar at the
> same time. It is basically the same thing as long as the binary comes
> from somewhere else.
> Of course, we should not include calcite.jar into source distribution.
> However, maven-wrapper.jar is not something that is produced by
> Calcite's sources, so it should be fine.
>
> Vladimir
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Vladimir Sitnikov <si...@gmail.com>.
Julian> The Release Policy [1] states that for a (compiled) artifact
the source code has to be released alongside.
maven-wrapper.jar has nothing to do with Calcite's source codes, so
maven-wrapper.jar is not "a compiled version of the source", so [1]
does not apply here.
It is the very same thing as "binary font file".
I don't see why the policy would allow *.ttf and forbid *.jar at the
same time. It is basically the same thing as long as the binary comes
from somewhere else.
Of course, we should not include calcite.jar into source distribution.
However, maven-wrapper.jar is not something that is produced by
Calcite's sources, so it should be fine.
Vladimir
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi Vladimir,
without beeing a super expert I guess the term "binary" in this context refers to a compiled package.
The Release Policy [1] states that for a (compiled) artifact the source code has to be released alongside.
So the images are basically the source for the homepage or documentation and the csv.gz files are necessary for testing (and thus building) the project.
The Maven Wrapper on the other hand is pre-compiled software but its source is not published with the release (as it has nothing to do with the software).
If I understand the policy correctly it would be okay to include the calcite jars in the release (as we do via maven central).
So I guess the term "binary" is a bit misleading.
Julian
[1] https://www.apache.org/legal/release-policy.html#compiled-packages
Am 15.03.19, 08:08 schrieb "Vladimir Sitnikov" <si...@gmail.com>:
Julian> maven-wrapper.jar is a binary file, and we cannot have binary
files in source distributions.
Hey, Julian, that is a great finding!
Can you please clarify if the following binary files count towards -1 as well?
site/img/pie-chart.png
site/img/cake.jpg
site/img/pb-calcite-140.png
site/img/pb-calcite-240.png
site/img/powered-by.png
site/img/window-types.png
site/img/logo.png
site/img/feather.png
site/fonts/fontawesome-webfont.ttf
site/fonts/fontawesome-webfont.woff
site/fonts/fontawesome-webfont.eot
file/src/test/resources/sales-csv/EMPS.csv.gz
example/csv/src/test/resources/sales/EMPS.csv.gz
Vladimir
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Vladimir Sitnikov <si...@gmail.com>.
Julian> maven-wrapper.jar is a binary file, and we cannot have binary
files in source distributions.
Hey, Julian, that is a great finding!
Can you please clarify if the following binary files count towards -1 as well?
site/img/pie-chart.png
site/img/cake.jpg
site/img/pb-calcite-140.png
site/img/pb-calcite-240.png
site/img/powered-by.png
site/img/window-types.png
site/img/logo.png
site/img/feather.png
site/fonts/fontawesome-webfont.ttf
site/fonts/fontawesome-webfont.woff
site/fonts/fontawesome-webfont.eot
file/src/test/resources/sales-csv/EMPS.csv.gz
example/csv/src/test/resources/sales/EMPS.csv.gz
Vladimir
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Julian Hyde <jh...@apache.org>.
-1 due to .mvn/wrapper/maven-wrapper.jar
maven-wrapper.jar is a binary file, and we cannot have binary files in source distributions. (Note that ./mvnw can bootstrap just fine without it. Also note that it is not checked into git — I guess it is created during the release build process.)
Everything else was fine. Checked hashes, KEYS, LICENSE, NOTICE, README; checked that contents of tar match git; compiled and ran tests using JDK 11 on Ubuntu linux.
Julian
> On Mar 14, 2019, at 10:30 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> +1 (binding)
>
> Checksum matches, the code compiles.
> Release notes look ok.
>
> Thanks, Kevin
>
> Vladimir
Re: [VOTE] Release apache-calcite-1.19.0 (release candidate 0)
Posted by Vladimir Sitnikov <si...@gmail.com>.
+1 (binding)
Checksum matches, the code compiles.
Release notes look ok.
Thanks, Kevin
Vladimir