You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Ruben Quesada Lopez <ru...@apache.org> on 2020/10/03 15:09:00 UTC
[VOTE] Release apache-calcite-1.26.0 (release candidate 0)
Hi all,
I have created a build for Apache Calcite 1.26.0, release
candidate 0.
Thanks to everyone who has contributed to this release.
You can read the release notes here:
https://apache.github.io/calcite-site-preview/docs/history.html
The commit to be voted upon:
https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=cfa37c3fd6ae18894035721d9f1eacde40e6b268
Its hash is cfa37c3fd6ae18894035721d9f1eacde40e6b268
Tag:
https://github.com/apache/calcite/tree/calcite-1.26.0-rc0
The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.26.0-rc0
(revision 41687)
RAT report:
https://apache.github.io/calcite-site-preview/rat/rat-report.txt
Site preview is here:
https://apache.github.io/calcite-site-preview/
JavaDoc API preview is here:
https://apache.github.io/calcite-site-preview/api
The hashes of the artifacts are as follows:
a8a0ed70d62bb697c64bb95aea3b9811157c2ef77ff5e937912ec5cf1f2db1b8a69ffb0529f89a32d6f8efe049f39e04669839a59cbf7bac8a8086d7c065742b
*apache-calcite-1.26.0-src.tar.gz
A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1101/org/apache/calcite/
Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/rubenql.asc
https://www.apache.org/dist/calcite/KEYS
N.B.
To create the jars and test Apache Calcite: "./gradlew build".
If you do not have a Java environment available, you can run the tests
using docker. To do so, install docker and docker-compose, then run
"docker-compose run test" from the root of the directory.
Please vote on releasing this package as Apache Calcite 1.26.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.26.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)
Re: DISCUSS: release vote text (was [VOTE] Release
apache-calcite-1.26.0)
Posted by John S <ap...@gmail.com>.
I tend to just follow the discussions here, but I was also curious.
I think it works by combining:
https://github.com/apache/calcite/blob/master/release/build.gradle.kts <https://github.com/apache/calcite/blob/master/release/build.gradle.kts>
With
https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/stage-vote-release-plugin <https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/stage-vote-release-plugin>
- jfs
> On Oct 6, 2020, at 11:46 AM, Julian Hyde <jh...@apache.org> wrote:
>
> Where does the script live that generates the vote email? I don't
> think it's even in our code base.
>
> Julian
>
> On Tue, Oct 6, 2020 at 11:33 AM Ruben Q L <ru...@gmail.com> wrote:
>>
>> Hi all,
>>
>> First of all, I apologize, this was my mistake, as I should have double
>> checked the content (and the links) of the email.
>> FYI, I have created https://issues.apache.org/jira/browse/CALCITE-4312 to
>> track this issue.
>>
>> Best,
>> Ruben
>>
>>
>> On Tue, Oct 6, 2020 at 7:15 PM Julian Hyde <jh...@apache.org> wrote:
>>
>>> The release email has been getting longer and longer because each
>>> release manager seems to want to add 'helpful' stuff. But we need to
>>> stay focused on the goal of the release vote: verify the integrity of
>>> the source distribution.
>>>
>>> The extra stuff in the email can be a distraction from that task.
>>>
>>> I was not able to vote on the release on Saturday because there was no
>>> working link to release notes. And on Tuesday morning, as I write
>>> this, the vote has been closed already. So, please go back to what we
>>> used to do: a link to the release notes in the github tag, like this:
>>>
>>> https://github.com/apache/calcite/blob/calcite-1.24.0-rc0/site/_docs/history.md
>>>
>>> It's not good to rely on shared scripts. The release vote is the last
>>> chance for humans to find stuff that the automation has missed. If
>>> we're all using the same script, we'll all test the same things and
>>> miss the same things.
>>>
>>> To repeat, we should remove the build instructions from the email.
>>> Every reviewer should download the tarball, and follow the
>>> instructions in the tarball. Otherwise you're not verifying the
>>> release, you're verifying what you imagine to be the release.
>>>
>>> Julian
>>>
>>> On Tue, Oct 6, 2020 at 7:45 AM Stamatis Zampetakis <za...@gmail.com>
>>> wrote:
>>>>
>>>> I'm fine with the content of the email but obviously we should not put
>>>> inside things that do not work.
>>>> If we don't have a site preview then it is confusing to have a broken
>>> link
>>>> in the vote email and the same goes for the rest.
>>>>
>>>> Best,
>>>> Stamatis
>>>>
>>>> On Sat, Oct 3, 2020 at 9:11 PM Vladimir Sitnikov <
>>>> sitnikov.vladimir@gmail.com> wrote:
>>>>
>>>>> Julian>Also, please don't double-space the email; if you get extra
>>>>> linefeeds
>>>>> when you copy-paste, remove them manually
>>>>>
>>>>> +100500
>>>>>
>>>>> Julian>The release notes
>>>>> Julian>should be at a URL whose contents will not change after the vote
>>>>> (not
>>>>> Julian>in the site preview)
>>>>>
>>>>> Where does that requirement come from?
>>>>> Release notes are volatile, and they are subject to further refinement.
>>>>> For instance, if we identify a regression, then we could update old
>>> notes
>>>>> to mention the regression.
>>>>>
>>>>> ---
>>>>>
>>>>> Just in case, here's a sample vote mail for Apache JMeter (all the
>>> links
>>>>> are working there):
>>>>>
>>>>>
>>> https://lists.apache.org/thread.html/228e422bd97f55717d06406664d6727b6e1294d2b906b8eff8453cea%40%3Cdev.jmeter.apache.org%3E
>>>>>
>>>>>
>>>>> Julian>much of the other site preview stuff
>>>>>
>>>>> Site preview is non-trivial to generate (it might require Docker or
>>>>> whatever).
>>>>>
>>>>> On top of that, if JavaDoc was shared in a clickable way, then we could
>>>>> review
>>>>> the documentation for the newly added features.
>>>>>
>>>>> Julian>the release should be self-contained and self-explanatory,
>>> right?
>>>>>
>>>>> I'm afraid if we remove all the links and instructions, the number of
>>> the
>>>>> number of
>>>>> votes would drop dramatically. The quality would drop as well, as
>>> people
>>>>> would
>>>>> skip things.
>>>>>
>>>>>
>>>>> I would clarify: even though we use Gradle for a while,
>>>>> people might be not familiar with the command to prepare release
>>> artifacts.
>>>>> On top of that, they might be shy admitting they have no idea how to
>>> build
>>>>> artifacts and where to find them.
>>>>>
>>>>> That is why I added the exact command to reproduce the release artifact
>>>>> in the initial draft of the vote mail (./gradlew build -Prelease
>>>>> -PskipSign).
>>>>> That command enables us to reproduce the artifact byte-by-byte.
>>>>> For some reason, someone suggested removing options from the command,
>>>>> and it was strange to me as "gradlew build" produces a slightly
>>> different
>>>>> archive.
>>>>>
>>>>> Even though I know all the commands and locations, I would love to add
>>>>> the sequence of shell scripts to validate the artifacts.
>>>>>
>>>>> Here's the script I use to validate Apache JMeter releases:
>>>>>
>>>>>
>>> https://lists.apache.org/thread.html/9127d0d5036c845ab882e0f2d0d7df7faf3e20855c07fc4b1c5c50ab%40%3Cdev.jmeter.apache.org%3E
>>>>>
>>>>> In my point of view, a sequence of commands to validate the release
>>>>> would definitely help, and we would get more votes.
>>>>>
>>>>> Julian>We definitely don't need the RAT report
>>>>>
>>>>> I'm -0 on that. ASF policy says that the licensing is of utter
>>> importance,
>>>>> so RAT report is important.
>>>>> On the other hand, RAT violations would fail the build, so the report
>>> is
>>>>> not very useful.
>>>>> However, it does highlight binary files (which we don't expect to have
>>> a
>>>>> lot).
>>>>>
>>>>> Frankly speaking, I can easily review RAT report if it is provided via
>>>>> link, however,
>>>>> it is likely I won't generate one on my own.
>>>>>
>>>>> For those who are curious, you might check JMeter's report:
>>>>> https://jmeter-preview.apache.org/rat/
>>>>>
>>>>> Vladimir
>>>>>
>>>
Re: DISCUSS: release vote text (was [VOTE] Release apache-calcite-1.26.0)
Posted by Julian Hyde <jh...@apache.org>.
Where does the script live that generates the vote email? I don't
think it's even in our code base.
Julian
On Tue, Oct 6, 2020 at 11:33 AM Ruben Q L <ru...@gmail.com> wrote:
>
> Hi all,
>
> First of all, I apologize, this was my mistake, as I should have double
> checked the content (and the links) of the email.
> FYI, I have created https://issues.apache.org/jira/browse/CALCITE-4312 to
> track this issue.
>
> Best,
> Ruben
>
>
> On Tue, Oct 6, 2020 at 7:15 PM Julian Hyde <jh...@apache.org> wrote:
>
> > The release email has been getting longer and longer because each
> > release manager seems to want to add 'helpful' stuff. But we need to
> > stay focused on the goal of the release vote: verify the integrity of
> > the source distribution.
> >
> > The extra stuff in the email can be a distraction from that task.
> >
> > I was not able to vote on the release on Saturday because there was no
> > working link to release notes. And on Tuesday morning, as I write
> > this, the vote has been closed already. So, please go back to what we
> > used to do: a link to the release notes in the github tag, like this:
> >
> > https://github.com/apache/calcite/blob/calcite-1.24.0-rc0/site/_docs/history.md
> >
> > It's not good to rely on shared scripts. The release vote is the last
> > chance for humans to find stuff that the automation has missed. If
> > we're all using the same script, we'll all test the same things and
> > miss the same things.
> >
> > To repeat, we should remove the build instructions from the email.
> > Every reviewer should download the tarball, and follow the
> > instructions in the tarball. Otherwise you're not verifying the
> > release, you're verifying what you imagine to be the release.
> >
> > Julian
> >
> > On Tue, Oct 6, 2020 at 7:45 AM Stamatis Zampetakis <za...@gmail.com>
> > wrote:
> > >
> > > I'm fine with the content of the email but obviously we should not put
> > > inside things that do not work.
> > > If we don't have a site preview then it is confusing to have a broken
> > link
> > > in the vote email and the same goes for the rest.
> > >
> > > Best,
> > > Stamatis
> > >
> > > On Sat, Oct 3, 2020 at 9:11 PM Vladimir Sitnikov <
> > > sitnikov.vladimir@gmail.com> wrote:
> > >
> > > > Julian>Also, please don't double-space the email; if you get extra
> > > > linefeeds
> > > > when you copy-paste, remove them manually
> > > >
> > > > +100500
> > > >
> > > > Julian>The release notes
> > > > Julian>should be at a URL whose contents will not change after the vote
> > > > (not
> > > > Julian>in the site preview)
> > > >
> > > > Where does that requirement come from?
> > > > Release notes are volatile, and they are subject to further refinement.
> > > > For instance, if we identify a regression, then we could update old
> > notes
> > > > to mention the regression.
> > > >
> > > > ---
> > > >
> > > > Just in case, here's a sample vote mail for Apache JMeter (all the
> > links
> > > > are working there):
> > > >
> > > >
> > https://lists.apache.org/thread.html/228e422bd97f55717d06406664d6727b6e1294d2b906b8eff8453cea%40%3Cdev.jmeter.apache.org%3E
> > > >
> > > >
> > > > Julian>much of the other site preview stuff
> > > >
> > > > Site preview is non-trivial to generate (it might require Docker or
> > > > whatever).
> > > >
> > > > On top of that, if JavaDoc was shared in a clickable way, then we could
> > > > review
> > > > the documentation for the newly added features.
> > > >
> > > > Julian>the release should be self-contained and self-explanatory,
> > right?
> > > >
> > > > I'm afraid if we remove all the links and instructions, the number of
> > the
> > > > number of
> > > > votes would drop dramatically. The quality would drop as well, as
> > people
> > > > would
> > > > skip things.
> > > >
> > > >
> > > > I would clarify: even though we use Gradle for a while,
> > > > people might be not familiar with the command to prepare release
> > artifacts.
> > > > On top of that, they might be shy admitting they have no idea how to
> > build
> > > > artifacts and where to find them.
> > > >
> > > > That is why I added the exact command to reproduce the release artifact
> > > > in the initial draft of the vote mail (./gradlew build -Prelease
> > > > -PskipSign).
> > > > That command enables us to reproduce the artifact byte-by-byte.
> > > > For some reason, someone suggested removing options from the command,
> > > > and it was strange to me as "gradlew build" produces a slightly
> > different
> > > > archive.
> > > >
> > > > Even though I know all the commands and locations, I would love to add
> > > > the sequence of shell scripts to validate the artifacts.
> > > >
> > > > Here's the script I use to validate Apache JMeter releases:
> > > >
> > > >
> > https://lists.apache.org/thread.html/9127d0d5036c845ab882e0f2d0d7df7faf3e20855c07fc4b1c5c50ab%40%3Cdev.jmeter.apache.org%3E
> > > >
> > > > In my point of view, a sequence of commands to validate the release
> > > > would definitely help, and we would get more votes.
> > > >
> > > > Julian>We definitely don't need the RAT report
> > > >
> > > > I'm -0 on that. ASF policy says that the licensing is of utter
> > importance,
> > > > so RAT report is important.
> > > > On the other hand, RAT violations would fail the build, so the report
> > is
> > > > not very useful.
> > > > However, it does highlight binary files (which we don't expect to have
> > a
> > > > lot).
> > > >
> > > > Frankly speaking, I can easily review RAT report if it is provided via
> > > > link, however,
> > > > it is likely I won't generate one on my own.
> > > >
> > > > For those who are curious, you might check JMeter's report:
> > > > https://jmeter-preview.apache.org/rat/
> > > >
> > > > Vladimir
> > > >
> >
Re: DISCUSS: release vote text (was [VOTE] Release apache-calcite-1.26.0)
Posted by Ruben Q L <ru...@gmail.com>.
Hi all,
First of all, I apologize, this was my mistake, as I should have double
checked the content (and the links) of the email.
FYI, I have created https://issues.apache.org/jira/browse/CALCITE-4312 to
track this issue.
Best,
Ruben
On Tue, Oct 6, 2020 at 7:15 PM Julian Hyde <jh...@apache.org> wrote:
> The release email has been getting longer and longer because each
> release manager seems to want to add 'helpful' stuff. But we need to
> stay focused on the goal of the release vote: verify the integrity of
> the source distribution.
>
> The extra stuff in the email can be a distraction from that task.
>
> I was not able to vote on the release on Saturday because there was no
> working link to release notes. And on Tuesday morning, as I write
> this, the vote has been closed already. So, please go back to what we
> used to do: a link to the release notes in the github tag, like this:
>
> https://github.com/apache/calcite/blob/calcite-1.24.0-rc0/site/_docs/history.md
>
> It's not good to rely on shared scripts. The release vote is the last
> chance for humans to find stuff that the automation has missed. If
> we're all using the same script, we'll all test the same things and
> miss the same things.
>
> To repeat, we should remove the build instructions from the email.
> Every reviewer should download the tarball, and follow the
> instructions in the tarball. Otherwise you're not verifying the
> release, you're verifying what you imagine to be the release.
>
> Julian
>
> On Tue, Oct 6, 2020 at 7:45 AM Stamatis Zampetakis <za...@gmail.com>
> wrote:
> >
> > I'm fine with the content of the email but obviously we should not put
> > inside things that do not work.
> > If we don't have a site preview then it is confusing to have a broken
> link
> > in the vote email and the same goes for the rest.
> >
> > Best,
> > Stamatis
> >
> > On Sat, Oct 3, 2020 at 9:11 PM Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com> wrote:
> >
> > > Julian>Also, please don't double-space the email; if you get extra
> > > linefeeds
> > > when you copy-paste, remove them manually
> > >
> > > +100500
> > >
> > > Julian>The release notes
> > > Julian>should be at a URL whose contents will not change after the vote
> > > (not
> > > Julian>in the site preview)
> > >
> > > Where does that requirement come from?
> > > Release notes are volatile, and they are subject to further refinement.
> > > For instance, if we identify a regression, then we could update old
> notes
> > > to mention the regression.
> > >
> > > ---
> > >
> > > Just in case, here's a sample vote mail for Apache JMeter (all the
> links
> > > are working there):
> > >
> > >
> https://lists.apache.org/thread.html/228e422bd97f55717d06406664d6727b6e1294d2b906b8eff8453cea%40%3Cdev.jmeter.apache.org%3E
> > >
> > >
> > > Julian>much of the other site preview stuff
> > >
> > > Site preview is non-trivial to generate (it might require Docker or
> > > whatever).
> > >
> > > On top of that, if JavaDoc was shared in a clickable way, then we could
> > > review
> > > the documentation for the newly added features.
> > >
> > > Julian>the release should be self-contained and self-explanatory,
> right?
> > >
> > > I'm afraid if we remove all the links and instructions, the number of
> the
> > > number of
> > > votes would drop dramatically. The quality would drop as well, as
> people
> > > would
> > > skip things.
> > >
> > >
> > > I would clarify: even though we use Gradle for a while,
> > > people might be not familiar with the command to prepare release
> artifacts.
> > > On top of that, they might be shy admitting they have no idea how to
> build
> > > artifacts and where to find them.
> > >
> > > That is why I added the exact command to reproduce the release artifact
> > > in the initial draft of the vote mail (./gradlew build -Prelease
> > > -PskipSign).
> > > That command enables us to reproduce the artifact byte-by-byte.
> > > For some reason, someone suggested removing options from the command,
> > > and it was strange to me as "gradlew build" produces a slightly
> different
> > > archive.
> > >
> > > Even though I know all the commands and locations, I would love to add
> > > the sequence of shell scripts to validate the artifacts.
> > >
> > > Here's the script I use to validate Apache JMeter releases:
> > >
> > >
> https://lists.apache.org/thread.html/9127d0d5036c845ab882e0f2d0d7df7faf3e20855c07fc4b1c5c50ab%40%3Cdev.jmeter.apache.org%3E
> > >
> > > In my point of view, a sequence of commands to validate the release
> > > would definitely help, and we would get more votes.
> > >
> > > Julian>We definitely don't need the RAT report
> > >
> > > I'm -0 on that. ASF policy says that the licensing is of utter
> importance,
> > > so RAT report is important.
> > > On the other hand, RAT violations would fail the build, so the report
> is
> > > not very useful.
> > > However, it does highlight binary files (which we don't expect to have
> a
> > > lot).
> > >
> > > Frankly speaking, I can easily review RAT report if it is provided via
> > > link, however,
> > > it is likely I won't generate one on my own.
> > >
> > > For those who are curious, you might check JMeter's report:
> > > https://jmeter-preview.apache.org/rat/
> > >
> > > Vladimir
> > >
>
Re: DISCUSS: release vote text (was [VOTE] Release apache-calcite-1.26.0)
Posted by Julian Hyde <jh...@apache.org>.
The release email has been getting longer and longer because each
release manager seems to want to add 'helpful' stuff. But we need to
stay focused on the goal of the release vote: verify the integrity of
the source distribution.
The extra stuff in the email can be a distraction from that task.
I was not able to vote on the release on Saturday because there was no
working link to release notes. And on Tuesday morning, as I write
this, the vote has been closed already. So, please go back to what we
used to do: a link to the release notes in the github tag, like this:
https://github.com/apache/calcite/blob/calcite-1.24.0-rc0/site/_docs/history.md
It's not good to rely on shared scripts. The release vote is the last
chance for humans to find stuff that the automation has missed. If
we're all using the same script, we'll all test the same things and
miss the same things.
To repeat, we should remove the build instructions from the email.
Every reviewer should download the tarball, and follow the
instructions in the tarball. Otherwise you're not verifying the
release, you're verifying what you imagine to be the release.
Julian
On Tue, Oct 6, 2020 at 7:45 AM Stamatis Zampetakis <za...@gmail.com> wrote:
>
> I'm fine with the content of the email but obviously we should not put
> inside things that do not work.
> If we don't have a site preview then it is confusing to have a broken link
> in the vote email and the same goes for the rest.
>
> Best,
> Stamatis
>
> On Sat, Oct 3, 2020 at 9:11 PM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
> > Julian>Also, please don't double-space the email; if you get extra
> > linefeeds
> > when you copy-paste, remove them manually
> >
> > +100500
> >
> > Julian>The release notes
> > Julian>should be at a URL whose contents will not change after the vote
> > (not
> > Julian>in the site preview)
> >
> > Where does that requirement come from?
> > Release notes are volatile, and they are subject to further refinement.
> > For instance, if we identify a regression, then we could update old notes
> > to mention the regression.
> >
> > ---
> >
> > Just in case, here's a sample vote mail for Apache JMeter (all the links
> > are working there):
> >
> > https://lists.apache.org/thread.html/228e422bd97f55717d06406664d6727b6e1294d2b906b8eff8453cea%40%3Cdev.jmeter.apache.org%3E
> >
> >
> > Julian>much of the other site preview stuff
> >
> > Site preview is non-trivial to generate (it might require Docker or
> > whatever).
> >
> > On top of that, if JavaDoc was shared in a clickable way, then we could
> > review
> > the documentation for the newly added features.
> >
> > Julian>the release should be self-contained and self-explanatory, right?
> >
> > I'm afraid if we remove all the links and instructions, the number of the
> > number of
> > votes would drop dramatically. The quality would drop as well, as people
> > would
> > skip things.
> >
> >
> > I would clarify: even though we use Gradle for a while,
> > people might be not familiar with the command to prepare release artifacts.
> > On top of that, they might be shy admitting they have no idea how to build
> > artifacts and where to find them.
> >
> > That is why I added the exact command to reproduce the release artifact
> > in the initial draft of the vote mail (./gradlew build -Prelease
> > -PskipSign).
> > That command enables us to reproduce the artifact byte-by-byte.
> > For some reason, someone suggested removing options from the command,
> > and it was strange to me as "gradlew build" produces a slightly different
> > archive.
> >
> > Even though I know all the commands and locations, I would love to add
> > the sequence of shell scripts to validate the artifacts.
> >
> > Here's the script I use to validate Apache JMeter releases:
> >
> > https://lists.apache.org/thread.html/9127d0d5036c845ab882e0f2d0d7df7faf3e20855c07fc4b1c5c50ab%40%3Cdev.jmeter.apache.org%3E
> >
> > In my point of view, a sequence of commands to validate the release
> > would definitely help, and we would get more votes.
> >
> > Julian>We definitely don't need the RAT report
> >
> > I'm -0 on that. ASF policy says that the licensing is of utter importance,
> > so RAT report is important.
> > On the other hand, RAT violations would fail the build, so the report is
> > not very useful.
> > However, it does highlight binary files (which we don't expect to have a
> > lot).
> >
> > Frankly speaking, I can easily review RAT report if it is provided via
> > link, however,
> > it is likely I won't generate one on my own.
> >
> > For those who are curious, you might check JMeter's report:
> > https://jmeter-preview.apache.org/rat/
> >
> > Vladimir
> >
Re: DISCUSS: release vote text (was [VOTE] Release apache-calcite-1.26.0)
Posted by Stamatis Zampetakis <za...@gmail.com>.
I'm fine with the content of the email but obviously we should not put
inside things that do not work.
If we don't have a site preview then it is confusing to have a broken link
in the vote email and the same goes for the rest.
Best,
Stamatis
On Sat, Oct 3, 2020 at 9:11 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Julian>Also, please don't double-space the email; if you get extra
> linefeeds
> when you copy-paste, remove them manually
>
> +100500
>
> Julian>The release notes
> Julian>should be at a URL whose contents will not change after the vote
> (not
> Julian>in the site preview)
>
> Where does that requirement come from?
> Release notes are volatile, and they are subject to further refinement.
> For instance, if we identify a regression, then we could update old notes
> to mention the regression.
>
> ---
>
> Just in case, here's a sample vote mail for Apache JMeter (all the links
> are working there):
>
> https://lists.apache.org/thread.html/228e422bd97f55717d06406664d6727b6e1294d2b906b8eff8453cea%40%3Cdev.jmeter.apache.org%3E
>
>
> Julian>much of the other site preview stuff
>
> Site preview is non-trivial to generate (it might require Docker or
> whatever).
>
> On top of that, if JavaDoc was shared in a clickable way, then we could
> review
> the documentation for the newly added features.
>
> Julian>the release should be self-contained and self-explanatory, right?
>
> I'm afraid if we remove all the links and instructions, the number of the
> number of
> votes would drop dramatically. The quality would drop as well, as people
> would
> skip things.
>
>
> I would clarify: even though we use Gradle for a while,
> people might be not familiar with the command to prepare release artifacts.
> On top of that, they might be shy admitting they have no idea how to build
> artifacts and where to find them.
>
> That is why I added the exact command to reproduce the release artifact
> in the initial draft of the vote mail (./gradlew build -Prelease
> -PskipSign).
> That command enables us to reproduce the artifact byte-by-byte.
> For some reason, someone suggested removing options from the command,
> and it was strange to me as "gradlew build" produces a slightly different
> archive.
>
> Even though I know all the commands and locations, I would love to add
> the sequence of shell scripts to validate the artifacts.
>
> Here's the script I use to validate Apache JMeter releases:
>
> https://lists.apache.org/thread.html/9127d0d5036c845ab882e0f2d0d7df7faf3e20855c07fc4b1c5c50ab%40%3Cdev.jmeter.apache.org%3E
>
> In my point of view, a sequence of commands to validate the release
> would definitely help, and we would get more votes.
>
> Julian>We definitely don't need the RAT report
>
> I'm -0 on that. ASF policy says that the licensing is of utter importance,
> so RAT report is important.
> On the other hand, RAT violations would fail the build, so the report is
> not very useful.
> However, it does highlight binary files (which we don't expect to have a
> lot).
>
> Frankly speaking, I can easily review RAT report if it is provided via
> link, however,
> it is likely I won't generate one on my own.
>
> For those who are curious, you might check JMeter's report:
> https://jmeter-preview.apache.org/rat/
>
> Vladimir
>
DISCUSS: release vote text (was [VOTE] Release apache-calcite-1.26.0)
Posted by Vladimir Sitnikov <si...@gmail.com>.
Julian>Also, please don't double-space the email; if you get extra linefeeds
when you copy-paste, remove them manually
+100500
Julian>The release notes
Julian>should be at a URL whose contents will not change after the vote (not
Julian>in the site preview)
Where does that requirement come from?
Release notes are volatile, and they are subject to further refinement.
For instance, if we identify a regression, then we could update old notes
to mention the regression.
---
Just in case, here's a sample vote mail for Apache JMeter (all the links
are working there):
https://lists.apache.org/thread.html/228e422bd97f55717d06406664d6727b6e1294d2b906b8eff8453cea%40%3Cdev.jmeter.apache.org%3E
Julian>much of the other site preview stuff
Site preview is non-trivial to generate (it might require Docker or
whatever).
On top of that, if JavaDoc was shared in a clickable way, then we could
review
the documentation for the newly added features.
Julian>the release should be self-contained and self-explanatory, right?
I'm afraid if we remove all the links and instructions, the number of the
number of
votes would drop dramatically. The quality would drop as well, as people
would
skip things.
I would clarify: even though we use Gradle for a while,
people might be not familiar with the command to prepare release artifacts.
On top of that, they might be shy admitting they have no idea how to build
artifacts and where to find them.
That is why I added the exact command to reproduce the release artifact
in the initial draft of the vote mail (./gradlew build -Prelease
-PskipSign).
That command enables us to reproduce the artifact byte-by-byte.
For some reason, someone suggested removing options from the command,
and it was strange to me as "gradlew build" produces a slightly different
archive.
Even though I know all the commands and locations, I would love to add
the sequence of shell scripts to validate the artifacts.
Here's the script I use to validate Apache JMeter releases:
https://lists.apache.org/thread.html/9127d0d5036c845ab882e0f2d0d7df7faf3e20855c07fc4b1c5c50ab%40%3Cdev.jmeter.apache.org%3E
In my point of view, a sequence of commands to validate the release
would definitely help, and we would get more votes.
Julian>We definitely don't need the RAT report
I'm -0 on that. ASF policy says that the licensing is of utter importance,
so RAT report is important.
On the other hand, RAT violations would fail the build, so the report is
not very useful.
However, it does highlight binary files (which we don't expect to have a
lot).
Frankly speaking, I can easily review RAT report if it is provided via
link, however,
it is likely I won't generate one on my own.
For those who are curious, you might check JMeter's report:
https://jmeter-preview.apache.org/rat/
Vladimir
Re: [VOTE] Release apache-calcite-1.26.0 (release candidate 0)
Posted by Julian Hyde <jh...@apache.org>.
Thanks for preparing an RC.
Here's a link to the release notes:
https://github.com/apache/calcite/blob/cfa37c3fd6ae18894035721d9f1eacde40e6b268/site/_docs/history.md
These release vote emails are getting longer and longer. I don't think
that's a good thing, and we should discuss it in another thread. We
definitely don't need the RAT report (reviewers can generate it for
themselves) or much of the other site preview stuff. The release notes
should be at a URL whose contents will not change after the vote (not
in the site preview). We don't need build instructions in the email
(the release should be self-contained and self-explanatory, right?)
Also, please don't double-space the email; if you get extra linefeeds
when you copy-paste, remove them manually.
I'll review and vote later today.
Julian
On Sat, Oct 3, 2020 at 8:11 AM Ruben Quesada Lopez <ru...@apache.org> wrote:
>
> Hi all,
>
>
> I have created a build for Apache Calcite 1.26.0, release
>
> candidate 0.
>
>
> Thanks to everyone who has contributed to this release.
>
>
> You can read the release notes here:
>
> https://apache.github.io/calcite-site-preview/docs/history.html
>
>
> The commit to be voted upon:
>
> https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=cfa37c3fd6ae18894035721d9f1eacde40e6b268
>
>
> Its hash is cfa37c3fd6ae18894035721d9f1eacde40e6b268
>
>
> Tag:
>
> https://github.com/apache/calcite/tree/calcite-1.26.0-rc0
>
>
> The artifacts to be voted on are located here:
>
> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.26.0-rc0
>
> (revision 41687)
>
>
> RAT report:
>
> https://apache.github.io/calcite-site-preview/rat/rat-report.txt
>
>
> Site preview is here:
>
> https://apache.github.io/calcite-site-preview/
>
>
> JavaDoc API preview is here:
>
> https://apache.github.io/calcite-site-preview/api
>
>
> The hashes of the artifacts are as follows:
>
> a8a0ed70d62bb697c64bb95aea3b9811157c2ef77ff5e937912ec5cf1f2db1b8a69ffb0529f89a32d6f8efe049f39e04669839a59cbf7bac8a8086d7c065742b
>
> *apache-calcite-1.26.0-src.tar.gz
>
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/content/repositories/orgapachecalcite-1101/org/apache/calcite/
>
>
> Release artifacts are signed with the following key:
>
> https://people.apache.org/keys/committer/rubenql.asc
>
> https://www.apache.org/dist/calcite/KEYS
>
>
> N.B.
>
> To create the jars and test Apache Calcite: "./gradlew build".
>
>
> If you do not have a Java environment available, you can run the tests
>
> using docker. To do so, install docker and docker-compose, then run
>
> "docker-compose run test" from the root of the directory.
>
>
> Please vote on releasing this package as Apache Calcite 1.26.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.26.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)
Re: [VOTE] Release apache-calcite-1.26.0 (release candidate 0)
Posted by Enrico Olivelli <eo...@gmail.com>.
+1 (non binding)
Run tests (AdoptOpen JDK14)
Verified signature and sha512
Run tests of HerdDB. I noticed the new hard dependency on Geometry (but
there is an hacky workaround), and the new SEARCH operator, that looks
cool, even if it will require a few cycles to adapt code to the new
Operator (RexUtil to the rescue!)
Ruben,
I have found this trick in order to drop Geometry and JSON Path
dependencies.
https://github.com/diennea/herddb/pull/707
Thank for driving the release
Enrico
Il giorno mar 6 ott 2020 alle ore 05:31 Andrei Sereda <an...@sereda.cc> ha
scritto:
> +1 (non-binding).
>
> - build locally: ok
> - check git hash: ok
> - check sha512 for artifacts: ok
> - check GPG signature: ok
>
> openjdk version "1.8.0_212"
>
> Note that I'm getting 404 for your public GPG key located here:
> https://people.apache.org/keys/committer/rubenql.asc
> So I've used Calcite KEYS instead.
>
> Thanks for RC, Ruben!
>
>
> On Mon, Oct 5, 2020 at 10:46 PM Danny Chan <da...@apache.org> wrote:
>
> > +1 (binding).
> >
> > - run tests locally: ok
> > - verify the commit hash in git tag: ok
> > - check sha512: ok
> >
> > Environment:
> > - java version 1.8.0_151
> > - MacOS Mojave 10.14.6
> >
> > I also find the new introduced ersi library when i do upgrade for Flink.
> I
> > solves the problem by adding a dependency for it. It is awesome if we can
> > avoid it. But it is not a blocker I guess.
> >
> > Enrico Olivelli <eo...@gmail.com>于2020年10月5日 周一下午10:58写道：
> >
> > > Il giorno lun 5 ott 2020 alle ore 16:43 Ruben Q L <ru...@gmail.com>
> ha
> > >
> > > scritto:
> > >
> > >
> > >
> > > > Enrico,
> > >
> > > >
> > >
> > > > thanks for your feedback. I also had a similar experience with my
> > >
> > > > downstream project.
> > >
> > > >
> > >
> > > > If I am not mistaken, esri library so far was not necessary because
> it
> > > was
> > >
> > > > used just on Calcite test; however, as you say, now it is required
> > since
> > > it
> > >
> > > > is used for Calcite build.
> > >
> > > > The root cause of this change seems to be CALCITE-1861 [1],
> implemented
> > > via
> > >
> > > > [2]. I think there is not much we can do about it.
> > >
> > > >
> > >
> > >
> > >
> > > So probably this is the line that introduces that hard dependency
> > >
> > >
> > >
> >
> https://github.com/apache/calcite/commit/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0#diff-39080ab40de0df7a4df59ca135c79d2fR377
> > >
> > >
> > >
> > > I will try to find some fix, at least to not fail the loading of
> Programs
> > >
> > > class
> > >
> > > I am going to file a JIRA for this case
> > >
> > >
> > >
> > >
> > >
> > > Enrico
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > >
> > > > Regarding the new SEARCH operator, I also had to adjust my code.
> > >
> > > > For me, the easiest way to "keep things working as before" was
> > basically
> > >
> > > > adding a "RexUtil#expandSearch" call at the appropriate place in
> order
> > to
> > >
> > > > convert the SEARCH into its equivalent non-search expression.
> > >
> > > >
> > >
> > > > Best,
> > >
> > > > Ruben
> > >
> > > >
> > >
> > > > [1] https://issues.apache.org/jira/browse/CALCITE-1861
> > >
> > > > [2]
> > >
> > > >
> > >
> > > >
> > >
> >
> https://github.com/apache/calcite/commit/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0
> > >
> > > >
> > >
> > > >
> > >
> > > > On Mon, Oct 5, 2020 at 3:17 PM Enrico Olivelli <eo...@gmail.com>
> > >
> > > > wrote:
> > >
> > > >
> > >
> > > > > Ruben,
> > >
> > > > > I am testing the RC, I found that now it is mandatory to have
> > >
> > > > > "com.esri.geometry:esri-geometry-api" on the classpath in order to
> > use
> > >
> > > > the
> > >
> > > > > Programs class.
> > >
> > > > >
> > >
> > > > > In HerdDB we were excluding that third party dependency, and we
> would
> > >
> > > > like
> > >
> > > > > not to depend on it in order to bring in as few third party deps as
> > >
> > > > > possible (and have smaller binaries).
> > >
> > > > > So I would cast a -1
> > >
> > > > > (also it would be super good to not have to depend
> > >
> > > > > on com.jayway.jsonpath:json-path, but that needed dependency was
> > there
> > >
> > > > > before 1.26 and there is no need to change it now)
> > >
> > > > >
> > >
> > > > > I can try to work on this issue as soon as possible if you think it
> > is
> > >
> > > > > worth it.
> > >
> > > > >
> > >
> > > > > Apart from that we are trying to make it work to switch to the
> > "SEARCH"
> > >
> > > > > operator, that is a big behavior change.
> > >
> > > > > I guess there is no way to disable it. But I am fine with that, I
> > knew
> > >
> > > > that
> > >
> > > > > it is only a matter of implementing that operator as well.
> > >
> > > > >
> > >
> > > > > Enrico
> > >
> > > > >
> > >
> > > > > Il giorno lun 5 ott 2020 alle ore 14:42 Vladimir Sitnikov <
> > >
> > > > > sitnikov.vladimir@gmail.com> ha scritto:
> > >
> > > > >
> > >
> > > > > > Thanks for preparing an RC.
> > >
> > > > > >
> > >
> > > > > > +1
> > >
> > > > > >
> > >
> > > > > > Build works for me modulo
> > >
> > > > > > https://issues.apache.org/jira/browse/CALCITE-2816
> PsTableFunction
> > >
> > > > > > fails in Russian locale.
> > >
> > > > > >
> > >
> > > > > > Checksums match, signature validation passes.
> > >
> > > > > > The release notes look good.
> > >
> > > > > >
> > >
> > > > > > changelog> Compatibility: Guava versions 19.0 to 29.0-jre
> > >
> > > > > >
> > >
> > > > > > I see build scripts are using Guava 29.0-jre only. I guess Guava
> 19
> > >
> > > > > support
> > >
> > > > > > comes like "hope it works".
> > >
> > > > > >
> > >
> > > > > > Vladimir
> > >
> > > > > >
> > >
> > > > >
> > >
> > > >
> > >
> > >
> >
>
Re: [VOTE] Release apache-calcite-1.26.0 (release candidate 0)
Posted by Andrei Sereda <an...@sereda.cc>.
+1 (non-binding).
- build locally: ok
- check git hash: ok
- check sha512 for artifacts: ok
- check GPG signature: ok
openjdk version "1.8.0_212"
Note that I'm getting 404 for your public GPG key located here:
https://people.apache.org/keys/committer/rubenql.asc
So I've used Calcite KEYS instead.
Thanks for RC, Ruben!
On Mon, Oct 5, 2020 at 10:46 PM Danny Chan <da...@apache.org> wrote:
> +1 (binding).
>
> - run tests locally: ok
> - verify the commit hash in git tag: ok
> - check sha512: ok
>
> Environment:
> - java version 1.8.0_151
> - MacOS Mojave 10.14.6
>
> I also find the new introduced ersi library when i do upgrade for Flink. I
> solves the problem by adding a dependency for it. It is awesome if we can
> avoid it. But it is not a blocker I guess.
>
> Enrico Olivelli <eo...@gmail.com>于2020年10月5日 周一下午10:58写道：
>
> > Il giorno lun 5 ott 2020 alle ore 16:43 Ruben Q L <ru...@gmail.com> ha
> >
> > scritto:
> >
> >
> >
> > > Enrico,
> >
> > >
> >
> > > thanks for your feedback. I also had a similar experience with my
> >
> > > downstream project.
> >
> > >
> >
> > > If I am not mistaken, esri library so far was not necessary because it
> > was
> >
> > > used just on Calcite test; however, as you say, now it is required
> since
> > it
> >
> > > is used for Calcite build.
> >
> > > The root cause of this change seems to be CALCITE-1861 [1], implemented
> > via
> >
> > > [2]. I think there is not much we can do about it.
> >
> > >
> >
> >
> >
> > So probably this is the line that introduces that hard dependency
> >
> >
> >
> https://github.com/apache/calcite/commit/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0#diff-39080ab40de0df7a4df59ca135c79d2fR377
> >
> >
> >
> > I will try to find some fix, at least to not fail the loading of Programs
> >
> > class
> >
> > I am going to file a JIRA for this case
> >
> >
> >
> >
> >
> > Enrico
> >
> >
> >
> >
> >
> >
> >
> > >
> >
> > > Regarding the new SEARCH operator, I also had to adjust my code.
> >
> > > For me, the easiest way to "keep things working as before" was
> basically
> >
> > > adding a "RexUtil#expandSearch" call at the appropriate place in order
> to
> >
> > > convert the SEARCH into its equivalent non-search expression.
> >
> > >
> >
> > > Best,
> >
> > > Ruben
> >
> > >
> >
> > > [1] https://issues.apache.org/jira/browse/CALCITE-1861
> >
> > > [2]
> >
> > >
> >
> > >
> >
> https://github.com/apache/calcite/commit/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0
> >
> > >
> >
> > >
> >
> > > On Mon, Oct 5, 2020 at 3:17 PM Enrico Olivelli <eo...@gmail.com>
> >
> > > wrote:
> >
> > >
> >
> > > > Ruben,
> >
> > > > I am testing the RC, I found that now it is mandatory to have
> >
> > > > "com.esri.geometry:esri-geometry-api" on the classpath in order to
> use
> >
> > > the
> >
> > > > Programs class.
> >
> > > >
> >
> > > > In HerdDB we were excluding that third party dependency, and we would
> >
> > > like
> >
> > > > not to depend on it in order to bring in as few third party deps as
> >
> > > > possible (and have smaller binaries).
> >
> > > > So I would cast a -1
> >
> > > > (also it would be super good to not have to depend
> >
> > > > on com.jayway.jsonpath:json-path, but that needed dependency was
> there
> >
> > > > before 1.26 and there is no need to change it now)
> >
> > > >
> >
> > > > I can try to work on this issue as soon as possible if you think it
> is
> >
> > > > worth it.
> >
> > > >
> >
> > > > Apart from that we are trying to make it work to switch to the
> "SEARCH"
> >
> > > > operator, that is a big behavior change.
> >
> > > > I guess there is no way to disable it. But I am fine with that, I
> knew
> >
> > > that
> >
> > > > it is only a matter of implementing that operator as well.
> >
> > > >
> >
> > > > Enrico
> >
> > > >
> >
> > > > Il giorno lun 5 ott 2020 alle ore 14:42 Vladimir Sitnikov <
> >
> > > > sitnikov.vladimir@gmail.com> ha scritto:
> >
> > > >
> >
> > > > > Thanks for preparing an RC.
> >
> > > > >
> >
> > > > > +1
> >
> > > > >
> >
> > > > > Build works for me modulo
> >
> > > > > https://issues.apache.org/jira/browse/CALCITE-2816 PsTableFunction
> >
> > > > > fails in Russian locale.
> >
> > > > >
> >
> > > > > Checksums match, signature validation passes.
> >
> > > > > The release notes look good.
> >
> > > > >
> >
> > > > > changelog> Compatibility: Guava versions 19.0 to 29.0-jre
> >
> > > > >
> >
> > > > > I see build scripts are using Guava 29.0-jre only. I guess Guava 19
> >
> > > > support
> >
> > > > > comes like "hope it works".
> >
> > > > >
> >
> > > > > Vladimir
> >
> > > > >
> >
> > > >
> >
> > >
> >
> >
>
Re: [VOTE] Release apache-calcite-1.26.0 (release candidate 0)
Posted by Danny Chan <da...@apache.org>.
+1 (binding).
- run tests locally: ok
- verify the commit hash in git tag: ok
- check sha512: ok
Environment:
- java version 1.8.0_151
- MacOS Mojave 10.14.6
I also find the new introduced ersi library when i do upgrade for Flink. I
solves the problem by adding a dependency for it. It is awesome if we can
avoid it. But it is not a blocker I guess.
Enrico Olivelli <eo...@gmail.com>于2020年10月5日 周一下午10:58写道：
> Il giorno lun 5 ott 2020 alle ore 16:43 Ruben Q L <ru...@gmail.com> ha
>
> scritto:
>
>
>
> > Enrico,
>
> >
>
> > thanks for your feedback. I also had a similar experience with my
>
> > downstream project.
>
> >
>
> > If I am not mistaken, esri library so far was not necessary because it
> was
>
> > used just on Calcite test; however, as you say, now it is required since
> it
>
> > is used for Calcite build.
>
> > The root cause of this change seems to be CALCITE-1861 [1], implemented
> via
>
> > [2]. I think there is not much we can do about it.
>
> >
>
>
>
> So probably this is the line that introduces that hard dependency
>
>
> https://github.com/apache/calcite/commit/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0#diff-39080ab40de0df7a4df59ca135c79d2fR377
>
>
>
> I will try to find some fix, at least to not fail the loading of Programs
>
> class
>
> I am going to file a JIRA for this case
>
>
>
>
>
> Enrico
>
>
>
>
>
>
>
> >
>
> > Regarding the new SEARCH operator, I also had to adjust my code.
>
> > For me, the easiest way to "keep things working as before" was basically
>
> > adding a "RexUtil#expandSearch" call at the appropriate place in order to
>
> > convert the SEARCH into its equivalent non-search expression.
>
> >
>
> > Best,
>
> > Ruben
>
> >
>
> > [1] https://issues.apache.org/jira/browse/CALCITE-1861
>
> > [2]
>
> >
>
> >
> https://github.com/apache/calcite/commit/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0
>
> >
>
> >
>
> > On Mon, Oct 5, 2020 at 3:17 PM Enrico Olivelli <eo...@gmail.com>
>
> > wrote:
>
> >
>
> > > Ruben,
>
> > > I am testing the RC, I found that now it is mandatory to have
>
> > > "com.esri.geometry:esri-geometry-api" on the classpath in order to use
>
> > the
>
> > > Programs class.
>
> > >
>
> > > In HerdDB we were excluding that third party dependency, and we would
>
> > like
>
> > > not to depend on it in order to bring in as few third party deps as
>
> > > possible (and have smaller binaries).
>
> > > So I would cast a -1
>
> > > (also it would be super good to not have to depend
>
> > > on com.jayway.jsonpath:json-path, but that needed dependency was there
>
> > > before 1.26 and there is no need to change it now)
>
> > >
>
> > > I can try to work on this issue as soon as possible if you think it is
>
> > > worth it.
>
> > >
>
> > > Apart from that we are trying to make it work to switch to the "SEARCH"
>
> > > operator, that is a big behavior change.
>
> > > I guess there is no way to disable it. But I am fine with that, I knew
>
> > that
>
> > > it is only a matter of implementing that operator as well.
>
> > >
>
> > > Enrico
>
> > >
>
> > > Il giorno lun 5 ott 2020 alle ore 14:42 Vladimir Sitnikov <
>
> > > sitnikov.vladimir@gmail.com> ha scritto:
>
> > >
>
> > > > Thanks for preparing an RC.
>
> > > >
>
> > > > +1
>
> > > >
>
> > > > Build works for me modulo
>
> > > > https://issues.apache.org/jira/browse/CALCITE-2816 PsTableFunction
>
> > > > fails in Russian locale.
>
> > > >
>
> > > > Checksums match, signature validation passes.
>
> > > > The release notes look good.
>
> > > >
>
> > > > changelog> Compatibility: Guava versions 19.0 to 29.0-jre
>
> > > >
>
> > > > I see build scripts are using Guava 29.0-jre only. I guess Guava 19
>
> > > support
>
> > > > comes like "hope it works".
>
> > > >
>
> > > > Vladimir
>
> > > >
>
> > >
>
> >
>
>
Re: [VOTE] Release apache-calcite-1.26.0 (release candidate 0)
Posted by Enrico Olivelli <eo...@gmail.com>.
Il giorno lun 5 ott 2020 alle ore 16:43 Ruben Q L <ru...@gmail.com> ha
scritto:
> Enrico,
>
> thanks for your feedback. I also had a similar experience with my
> downstream project.
>
> If I am not mistaken, esri library so far was not necessary because it was
> used just on Calcite test; however, as you say, now it is required since it
> is used for Calcite build.
> The root cause of this change seems to be CALCITE-1861 [1], implemented via
> [2]. I think there is not much we can do about it.
>
So probably this is the line that introduces that hard dependency
https://github.com/apache/calcite/commit/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0#diff-39080ab40de0df7a4df59ca135c79d2fR377
I will try to find some fix, at least to not fail the loading of Programs
class
I am going to file a JIRA for this case
Enrico
>
> Regarding the new SEARCH operator, I also had to adjust my code.
> For me, the easiest way to "keep things working as before" was basically
> adding a "RexUtil#expandSearch" call at the appropriate place in order to
> convert the SEARCH into its equivalent non-search expression.
>
> Best,
> Ruben
>
> [1] https://issues.apache.org/jira/browse/CALCITE-1861
> [2]
>
> https://github.com/apache/calcite/commit/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0
>
>
> On Mon, Oct 5, 2020 at 3:17 PM Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > Ruben,
> > I am testing the RC, I found that now it is mandatory to have
> > "com.esri.geometry:esri-geometry-api" on the classpath in order to use
> the
> > Programs class.
> >
> > In HerdDB we were excluding that third party dependency, and we would
> like
> > not to depend on it in order to bring in as few third party deps as
> > possible (and have smaller binaries).
> > So I would cast a -1
> > (also it would be super good to not have to depend
> > on com.jayway.jsonpath:json-path, but that needed dependency was there
> > before 1.26 and there is no need to change it now)
> >
> > I can try to work on this issue as soon as possible if you think it is
> > worth it.
> >
> > Apart from that we are trying to make it work to switch to the "SEARCH"
> > operator, that is a big behavior change.
> > I guess there is no way to disable it. But I am fine with that, I knew
> that
> > it is only a matter of implementing that operator as well.
> >
> > Enrico
> >
> > Il giorno lun 5 ott 2020 alle ore 14:42 Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com> ha scritto:
> >
> > > Thanks for preparing an RC.
> > >
> > > +1
> > >
> > > Build works for me modulo
> > > https://issues.apache.org/jira/browse/CALCITE-2816 PsTableFunction
> > > fails in Russian locale.
> > >
> > > Checksums match, signature validation passes.
> > > The release notes look good.
> > >
> > > changelog> Compatibility: Guava versions 19.0 to 29.0-jre
> > >
> > > I see build scripts are using Guava 29.0-jre only. I guess Guava 19
> > support
> > > comes like "hope it works".
> > >
> > > Vladimir
> > >
> >
>
Re: [VOTE] Release apache-calcite-1.26.0 (release candidate 0)
Posted by Ruben Q L <ru...@gmail.com>.
Enrico,
thanks for your feedback. I also had a similar experience with my
downstream project.
If I am not mistaken, esri library so far was not necessary because it was
used just on Calcite test; however, as you say, now it is required since it
is used for Calcite build.
The root cause of this change seems to be CALCITE-1861 [1], implemented via
[2]. I think there is not much we can do about it.
Regarding the new SEARCH operator, I also had to adjust my code.
For me, the easiest way to "keep things working as before" was basically
adding a "RexUtil#expandSearch" call at the appropriate place in order to
convert the SEARCH into its equivalent non-search expression.
Best,
Ruben
[1] https://issues.apache.org/jira/browse/CALCITE-1861
[2]
https://github.com/apache/calcite/commit/eab043f4ef43112c16a9f6708e6c53a15b1cfbe0
On Mon, Oct 5, 2020 at 3:17 PM Enrico Olivelli <eo...@gmail.com> wrote:
> Ruben,
> I am testing the RC, I found that now it is mandatory to have
> "com.esri.geometry:esri-geometry-api" on the classpath in order to use the
> Programs class.
>
> In HerdDB we were excluding that third party dependency, and we would like
> not to depend on it in order to bring in as few third party deps as
> possible (and have smaller binaries).
> So I would cast a -1
> (also it would be super good to not have to depend
> on com.jayway.jsonpath:json-path, but that needed dependency was there
> before 1.26 and there is no need to change it now)
>
> I can try to work on this issue as soon as possible if you think it is
> worth it.
>
> Apart from that we are trying to make it work to switch to the "SEARCH"
> operator, that is a big behavior change.
> I guess there is no way to disable it. But I am fine with that, I knew that
> it is only a matter of implementing that operator as well.
>
> Enrico
>
> Il giorno lun 5 ott 2020 alle ore 14:42 Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> ha scritto:
>
> > Thanks for preparing an RC.
> >
> > +1
> >
> > Build works for me modulo
> > https://issues.apache.org/jira/browse/CALCITE-2816 PsTableFunction
> > fails in Russian locale.
> >
> > Checksums match, signature validation passes.
> > The release notes look good.
> >
> > changelog> Compatibility: Guava versions 19.0 to 29.0-jre
> >
> > I see build scripts are using Guava 29.0-jre only. I guess Guava 19
> support
> > comes like "hope it works".
> >
> > Vladimir
> >
>
Re: [VOTE] Release apache-calcite-1.26.0 (release candidate 0)
Posted by Enrico Olivelli <eo...@gmail.com>.
Ruben,
I am testing the RC, I found that now it is mandatory to have
"com.esri.geometry:esri-geometry-api" on the classpath in order to use the
Programs class.
In HerdDB we were excluding that third party dependency, and we would like
not to depend on it in order to bring in as few third party deps as
possible (and have smaller binaries).
So I would cast a -1
(also it would be super good to not have to depend
on com.jayway.jsonpath:json-path, but that needed dependency was there
before 1.26 and there is no need to change it now)
I can try to work on this issue as soon as possible if you think it is
worth it.
Apart from that we are trying to make it work to switch to the "SEARCH"
operator, that is a big behavior change.
I guess there is no way to disable it. But I am fine with that, I knew that
it is only a matter of implementing that operator as well.
Enrico
Il giorno lun 5 ott 2020 alle ore 14:42 Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> ha scritto:
> Thanks for preparing an RC.
>
> +1
>
> Build works for me modulo
> https://issues.apache.org/jira/browse/CALCITE-2816 PsTableFunction
> fails in Russian locale.
>
> Checksums match, signature validation passes.
> The release notes look good.
>
> changelog> Compatibility: Guava versions 19.0 to 29.0-jre
>
> I see build scripts are using Guava 29.0-jre only. I guess Guava 19 support
> comes like "hope it works".
>
> Vladimir
>
Re: [VOTE] Release apache-calcite-1.26.0 (release candidate 0)
Posted by Vladimir Sitnikov <si...@gmail.com>.
Thanks for preparing an RC.
+1
Build works for me modulo
https://issues.apache.org/jira/browse/CALCITE-2816 PsTableFunction
fails in Russian locale.
Checksums match, signature validation passes.
The release notes look good.
changelog> Compatibility: Guava versions 19.0 to 29.0-jre
I see build scripts are using Guava 29.0-jre only. I guess Guava 19 support
comes like "hope it works".
Vladimir