Re: [ANNOUNCE] New committer: Mihai Budiu

2023-10-26 Thread Andrei Sereda
Congratulations, Mihai!

On Thu, Oct 26, 2023 at 08:08 Ran Tao  wrote:

> Congratulations, Mihai !
> and thanks for the review in the issue and PR !
>
> Best Regards,
> Ran Tao
>
> Stamatis Zampetakis  于2023年10月26日周四 16:57写道:
>
> > Apache Calcite's Project Management Committee (PMC) has invited Mihai
> > Budiu to become a committer, and we are pleased to announce that he
> > has accepted.
> >
> > Mihai has addressed numerous compile and runtime issues in SQL
> > functions and has made several significant improvements to the test
> > infrastructure to enhance code coverage, quality, and stability. In
> > addition to code contributions, Mihai is highly active on the mailing
> > list, where he answers questions, assists others, and shares ideas for
> > future improvements. Mihai has also been writing blogs and giving
> > talks about Calcite at various events and conferences, showcasing
> > Calcite in both simple and more advanced use cases, which can greatly
> > contribute to the growth of the community.
> >
> > Mihai, welcome, thank you for your contributions, and we look forward
> > to your further interactions with the community! If you wish, please
> > feel free to tell us more about yourself and what you are working on.
> >
> > As your first commit, please add yourself to the contributors list [1]
> > and the community page will re-generate [2].
> >
> > Stamatis (on behalf of the Apache Calcite PMC)
> >
> > [1]
> > https://github.com/apache/calcite/blob/main/site/_data/contributors.yml
> > [2] https://calcite.apache.org/community/#project-members
> >
>


Re: [ANNOUNCE] New committer: Alex Plehanov

2023-01-10 Thread Andrei Sereda
Welcome, Alex!

On Tue, Jan 10, 2023, 11:01 Stamatis Zampetakis  wrote:

> Welcome Alex! Looking forward to working with you.
>
> Best,
> Stamatis
>
> On Tue, Jan 10, 2023 at 2:48 AM Chunwei Lei 
> wrote:
>
> > Welcome, Alex!
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Sun, Jan 8, 2023 at 3:59 PM Alex Plehanov 
> > wrote:
> >
> > > Hello,
> > >
> > > Thanks for the warm welcome! A couple of words about myself: In Apache
> > > Ignite we are developing the new SQL engine (based on Apache Calcite)
> as
> > a
> > > replacement for the old SQL engine. The old engine has some
> > > fundamental limitations which we can resolve with the help of Calcite.
> I
> > am
> > > one of the major contributors to this part of the Apache Ignite. The
> new
> > > SQL engine was first released with Ignite 2.13 (2022-04-26) but still
> in
> > > beta status. Our primary goal now - make it production ready.
> > >
> > > сб, 7 янв. 2023 г. в 08:45, Benchao Li :
> > >
> > > > Congratulations, Alex!
> > > >
> > > > Francis Chuang  于2023年1月7日周六 09:51写道:
> > > >
> > > > > Congrats, Alex!
> > > > >
> > > > > On 7/01/2023 5:17 am, Michael Mior wrote:
> > > > > > Welcome Alex!
> > > > > >
> > > > > > --
> > > > > > Michael Mior
> > > > > > mm...@apache.org
> > > > > >
> > > > > >
> > > > > > On Fri, Jan 6, 2023 at 6:04 AM Ruben Q L 
> > wrote:
> > > > > >
> > > > > >> Apache Calcite's Project Management Committee (PMC) has invited
> > Alex
> > > > > >> Plehanov to become a committer, and we are pleased to announce
> > that
> > > he
> > > > > has
> > > > > >> accepted the invitation.
> > > > > >>
> > > > > >> Alex is an Apache Ignite PMC member and the main author of the
> > > > > >> ignite-calcite module. He has done significant contributions on
> > > > Calcite,
> > > > > >> especially fixing bugs detected by Ignite.
> > > > > >>
> > > > > >> Alex, welcome, thank you for your contributions, and we look
> > forward
> > > > to
> > > > > >> your further interactions with the community! If you wish,
> please
> > > feel
> > > > > free
> > > > > >> to tell us a bit more about yourself and what you are currently
> > > > working
> > > > > on.
> > > > > >> As your first commit, you can add yourself to the contributors
> > list
> > > > [1]
> > > > > and
> > > > > >> the community page will re-generate [2].
> > > > > >>
> > > > > >> Ruben (on behalf of the Apache Calcite PMC)
> > > > > >>
> > > > > >> [1]
> > > > > >>
> > > >
> > https://github.com/apache/calcite/blob/main/site/_data/contributors.yml
> > > > > >> [2] https://calcite.apache.org/community/#project-members
> > > > > >>
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Best,
> > > > Benchao Li
> > > >
> > >
> >
>


Re: [ANNOUNCE] New committer: Dmitry Sysolyatin

2022-11-08 Thread Andrei Sereda
Congratulations!

On Tue, Nov 8, 2022, 16:08 Francis Chuang  wrote:

> Congratulations, Dmitry!
>
> Francis
>
> On 9/11/2022 6:13 am, Julian Hyde wrote:
> > Congratulations, Dmitry! Thanks for the great work you’ve already done
> for the project.
> >
> > Julian
> >
> >
> >> On Nov 8, 2022, at 10:56 AM, Alessandro Solimando <
> alessandro.solima...@gmail.com> wrote:
> >>
> >> Congrats Dmitry, welcome to Calcite!
> >>
> >> On Tue 8 Nov 2022, 18:44 Ruben Q L,  wrote:
> >>
> >>> Apache Calcite's Project Management Committee (PMC) has invited Dmitry
> >>> Sysolyatin to become a committer, and we are pleased to announce he has
> >>> accepted the invitation.
> >>>
> >>> During the last months Dmitry has pushed a lot of high quality patches,
> >>> fixing and improving code around several places in Calcite core. Apart
> from
> >>> code contributions, he has been regularly involved in discussions
> regarding
> >>> multiple topics in the mailing list, always with a hardworking and
> >>> courteous spirit.
> >>>
> >>> Dmitry, welcome, thank you for your contributions, and we look forward
> to
> >>> your further interactions with the community! If you wish, please feel
> free
> >>> to tell us a bit more about yourself and what you are currently
> working on.
> >>> As your first commit, you can add yourself to the contributors list
> [1] and
> >>> the community page will re-generate [2].
> >>>
> >>> Ruben (on behalf of the Apache Calcite PMC)
> >>>
> >>> [1]
> >>>
> https://github.com/apache/calcite/blob/main/site/_data/contributors.yml
> >>> [2] https://calcite.apache.org/community/#project-members
> >>>
> >
>


Re: [ANNOUNCE] Andrei Sereda joins Calcite PMC

2022-08-16 Thread Andrei Sereda
Hi All,

Thanks for your kind words.

I'm looking forward to our continued collaboration, expanding the
community and making Calcite a better framework.

Regards,
Andrei.

On Mon, Aug 15, 2022 at 8:03 AM Alessandro Solimando
 wrote:
>
> Congratulations Andrei and thanks again for driving the latest release!
>
> Il Lun 15 Ago 2022, 09:01 Yanjing Wang  ha
> scritto:
>
> > Congratulations, Andrei!
> >
> > Chunwei Lei  于2022年8月15日周一 10:11写道:
> >
> > > Congratulations, Andrei!
> > >
> > > Best,
> > > Chunwei
> > >
> > >
> > > On Sun, Aug 14, 2022 at 4:05 PM Jiajun Xie 
> > > wrote:
> > >
> > > > Congratulations, Andrei!
> > > >
> > > > On Sun, 14 Aug 2022 at 10:50, Benchao Li  wrote:
> > > >
> > > > > Congratulations Andrei!
> > > > >
> > > > > Francis Chuang  于2022年8月13日周六 09:53写道:
> > > > >
> > > > > > Congratulations Andrei!
> > > > > >
> > > > > > On 13/08/2022 5:29 am, Michael Mior wrote:
> > > > > > > Congratulations and welcome Andrei!
> > > > > > >
> > > > > > > --
> > > > > > > Michael Mior
> > > > > > > mm...@apache.org
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Aug 12, 2022 at 1:48 PM Ruben Q L 
> > > wrote:
> > > > > > >
> > > > > > >> I am pleased to announce that Andrei has accepted an invitation
> > to
> > > > > join
> > > > > > >> the Calcite PMC. Andrei has been a consistent and helpful figure
> > > in
> > > > > > >> the Calcite community for which we are very grateful. We look
> > > > forward
> > > > > to
> > > > > > >> the continued contributions and support.
> > > > > > >>
> > > > > > >> Please join me in congratulating Andrei!
> > > > > > >>
> > > > > > >> Ruben (on behalf of the Calcite PMC)
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Best,
> > > > > Benchao Li
> > > > >
> > > >
> > >
> >


Re: Calcite Release 1.31 started

2022-08-05 Thread Andrei Sereda
Hi,

Thanks for all your participation and help during this release.

Benchao, I've marked 1.31.0 as released in JIRA.

Andrei.

On Fri, Aug 5, 2022 at 4:12 AM Benchao Li  wrote:
>
> Hi Andrei,
>
> I found that the version "1.31.0" is still in "unreleased versions" in
> Jira. However, there is a version "1.31" which is in the "released
> versions".
>
> Jing Zhang  于2022年8月4日周四 23:33写道:
>
> > Thanks Andrei for making this happen!
> >
> > Best,
> > Jing Zhang
> >
> > Stamatis Zampetakis  于2022年8月4日周四 17:00写道:
> >
> > > Many thanks for getting this release out Andrei!
> > >
> > > Best,
> > > Stamatis
> > >
> > > On Thu, Aug 4, 2022 at 4:58 AM Charles Givre  wrote:
> > >
> > > > Thanks Andrei and Calcite team for 1.31!
> > > >
> > > > From the Drill community we are very excited about this release as we
> > > have
> > > > been working on a PR to get Drill back on the main version of Calcite.
> > (
> > > > https://github.com/apache/drill/pull/2602 <
> > > > https://github.com/apache/drill/pull/2602>)  We've been testing Drill
> > > > with Calcite 1.31 and we've seen very significant improvements in
> > > > performance.
> > > >
> > > > Best,
> > > > -- C
> > > >
> > > >
> > > >
> > > >
> > > > > On Aug 3, 2022, at 8:30 PM, Benchao Li  wrote:
> > > > >
> > > > > Thanks Andrei for being the RM for 1.31.0
> > > > >
> > > > >
> > > > > Gavin Ray  于2022年8月4日周四 02:46写道:
> > > > >
> > > > >> Hooray!!
> > > > >>
> > > > >> On Wed, Aug 3, 2022 at 2:34 PM Michael Mior 
> > wrote:
> > > > >>
> > > > >>> Thanks for all your work Andrei!
> > > > >>>
> > > > >>> --
> > > > >>> Michael Mior
> > > > >>> mm...@apache.org
> > > > >>>
> > > > >>>
> > > > >>> On Wed, Aug 3, 2022 at 12:44 PM Andrei Sereda 
> > > > wrote:
> > > > >>>
> > > > >>>> 1.31 has been released.
> > > > >>>>
> > > > >>>> You can resume dev work on the main branch.
> > > > >>>>
> > > > >>>> Thanks for your patience.
> > > > >>>>
> > > > >>>>
> > > > >>>> On Wed, Jul 20, 2022 at 2:52 AM Andrei Sereda 
> > > > >> wrote:
> > > > >>>>
> > > > >>>>> Hello,
> > > > >>>>>
> > > > >>>>> I'm starting the Calcite 1.31 release. Main branch will be frozen
> > > > >> until
> > > > >>>>> completion.
> > > > >>>>>
> > > > >>>>> Please avoid committing anything to main until further notice.
> > > > >>>>>
> > > > >>>>> Andrei.
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Best,
> > > > > Benchao Li
> > > >
> > > >
> > >
> >
>
>
> --
>
> Best,
> Benchao Li


Re: Calcite Release 1.31 started

2022-08-03 Thread Andrei Sereda
1.31 has been released.

You can resume dev work on the main branch.

Thanks for your patience.


On Wed, Jul 20, 2022 at 2:52 AM Andrei Sereda  wrote:

> Hello,
>
> I'm starting the Calcite 1.31 release. Main branch will be frozen until
> completion.
>
> Please avoid committing anything to main until further notice.
>
> Andrei.
>


Re: [VOTE] Release Apache Calcite 1.31.0 (release candidate 3)

2022-08-02 Thread Andrei Sereda
Thanks everyone for testing and voting for this release.

The vote is currently closed and I will send a separate email with the
results.

On Mon, Aug 1, 2022 at 4:32 AM Chunwei Lei  wrote:

> Thanks Andrei for working on this.
>
> Mac OS X 10.16 x86_64,jdk 1.8.0_271,Gradle 7.3
>
> - Checksum and signature: ok
> - Gradle test: ok
> - Went over release note: ok
>
> My vote is: +1 (binding)
>
>
> Best,
> Chunwei
>
>
> On Sat, Jul 30, 2022 at 10:10 PM Stamatis Zampetakis 
> wrote:
>
> > Ubuntu 20.04.4 LTS, jdk1.8.0_261, Gradle wrapper, Gradle 7.4.2
> >
> >  * Checked signatures and checksums OK
> >  * Went over release note OK
> >  * Built from git tag and run tests (./gradlew clean build) OK
> >  * Built from source artifacts and run unit tests + slow tests OK
> >  * Checked diff between git repo and release sources OK
> >
> > +1 (binding)
> >
> > Best,
> > Stamatis
> >
> > On Sat, Jul 30, 2022 at 12:32 PM Francis Chuang <
> francischu...@apache.org>
> > wrote:
> >
> > > My vote is: +1 (binding)
> > >
> > > - Verified GPG signature - OK
> > > - Verified SHA512 - OK
> > > - Diffed source release and git repository - OK
> > > - Checked release notes on tag
> > > (
> > >
> >
> https://github.com/apache/calcite/blob/calcite-1.31.0-rc3/site/_docs/history.md
> > )
> > >
> > > - OK
> > > - Ran tests (gradle check) - OK
> > > - Spot checked Nexus artifacts - OK
> > >
> > > Environment:
> > > Eclipse-temurin:17-jammy docker container in WSL2 (Ubuntu 20.04) on
> > > Windows 10 21h2
> > >
> > >  > docker version
> > > Client: Docker Engine - Community
> > >   Cloud integration: v1.0.28
> > >   Version:   20.10.17
> > >   API version:   1.41
> > >   Go version:go1.17.11
> > >   Git commit:100c701
> > >   Built: Mon Jun  6 23:03:17 2022
> > >   OS/Arch:   linux/amd64
> > >   Context:   default
> > >   Experimental:  true
> > >
> > > Server: Docker Desktop
> > >   Engine:
> > >Version:  20.10.17
> > >API version:  1.41 (minimum version 1.12)
> > >Go version:   go1.17.11
> > >Git commit:   a89b842
> > >Built:Mon Jun  6 23:01:23 2022
> > >OS/Arch:  linux/amd64
> > >Experimental: false
> > >   containerd:
> > >Version:  1.6.6
> > >GitCommit:10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
> > >   runc:
> > >Version:  1.1.2
> > >GitCommit:v1.1.2-0-ga916309
> > >   docker-init:
> > >Version:  0.19.0
> > >GitCommit:de40ad0
> > >
> > >  > gradle -v
> > >
> > > 
> > > Gradle 7.4.2
> > > 
> > >
> > > Build time:   2022-03-31 15:25:29 UTC
> > > Revision: 540473b8118064efcc264694cbcaa4b677f61041
> > >
> > > Kotlin:   1.5.31
> > > Groovy:   3.0.9
> > > Ant:  Apache Ant(TM) version 1.10.11 compiled on July 10 2021
> > > JVM:  17.0.3 (Eclipse Adoptium 17.0.3+7)
> > > OS:   Linux 5.10.102.1-microsoft-standard-WSL2 amd64
> > >
> > >  > java -version
> > > openjdk version "17.0.3" 2022-04-19
> > > OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7)
> > > OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode,
> > > sharing)
> > >
> > > Francis
> > >
> > > On 30/07/2022 6:23 am, Julian Hyde wrote:
> > > > Downloaded, checked sums and signatures, LICENSE, NOTICE, README,
> > > howto.md, history.md; compiled and ran tests using OpenJDK 18, Gradle
> > 7.4.2
> > > on Ubuntu Linux 5.4.0 x86_64; ran rat.
> > > >
> > > > +1 (binding)
> > > >
> > > > Julian
> > > >
> > > >
> > > >> On Jul 29, 2022, at 8:48 AM, Benchao Li 
> wrote:
> > > >>
> > > >> +1 (non-binding)
> > > >>
> > > >> - checked signature and checksum: OK
> > > >> - build and test from source: OK
> > > >> - diff sources with release tag: OK
> > > >> - checked

[RESULT] [VOTE] Release Apache Calcite 1.31.0 (release candidate 3)

2022-08-02 Thread Andrei Sereda
Thanks to everyone who has tested the release candidate and given
their comments and votes.

The tally is as follows.

5 binding +1s:
Ruben Q L
Julian Hyde
Francis Chuang
Stamatis Zempetakis
Chunwei Lei

3 non-binding +1s:
Andrei Sereda
Enrico Olivelli
Benchao Li

No 0s or -1s.

Therefore, I am delighted to announce that the proposal to release
Apache Calcite 1.31.0 has passed.

Thanks everyone. We’ll now roll the release out to the mirrors.

There was some feedback during voting. I shall open a separate
thread to discuss.

Andrei


Re: [CANCELLED] Release Apache Calcite 1.31.0 (release candidate 1)

2022-07-29 Thread Andrei Sereda
I had to skip RC2 because of some changes to history.md (while the rc2 tag
was already created on gitbox).

The vote for RC3 has been sent.



On Fri, Jul 29, 2022 at 1:14 PM Andrei Sereda  wrote:

> Hello,
>
> Due to checksum mismatches, voting for RC1 is cancelled.
>
> I will send another vote for RC2 shortly.
>
> Regards,
> Andrei.
>


[VOTE] Release Apache Calcite 1.31.0 (release candidate 3)

2022-07-29 Thread Andrei Sereda
Hi all,

I have created a build for Apache Calcite 1.31.0, release
candidate 3.

Thanks to everyone who has contributed to this release.

You can read the release notes here:
https://github.com/apache/calcite/blob/calcite-1.31.0-rc3/site/_docs/history.md

The commit to be voted upon:
https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=86d1bf40e4799665951065fd5f4ee4a771e7b655

Its hash is 86d1bf40e4799665951065fd5f4ee4a771e7b655

Tag:
https://gitbox.apache.org/repos/asf?p=calcite.git;a=tag;h=refs/tags/calcite-1.31.0-rc3

The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.31.0-rc3
(revision 56034)

The hashes of the artifacts are as follows:
477848037465e883bc7f45d71a59be5932ddfc37d4fd4571f17d7463afe6cc3df1ab5bd20f38fb28fd6468d5b23f559eba4ff3adde9d4f689622e95abd736260
*apache-calcite-1.31.0-src.tar.gz

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1172/org/apache/calcite/

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/sereda.asc
https://www.apache.org/dist/calcite/KEYS

To create the jars and test Apache Calcite: "gradle build"
(requires an appropriate Gradle/JDK installation)

Please vote on releasing this package as Apache Calcite 1.31.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.31.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 (non-binding)


[CANCELLED] Release Apache Calcite 1.31.0 (release candidate 1)

2022-07-29 Thread Andrei Sereda
Hello,

Due to checksum mismatches, voting for RC1 is cancelled.

I will send another vote for RC2 shortly.

Regards,
Andrei.


Re: [VOTE] Release Apache Calcite 1.31.0 (release candidate 1)

2022-07-29 Thread Andrei Sereda
Apologies for taking your time. I will create RC2 shortly.

Please consider the vote for RC1 cancelled.

On Fri, Jul 29, 2022 at 11:09 AM Ruben Q L  wrote:

> I concur, there seems to be an issue with the checksum (I get the same
> result as Stamatis).
> Other checks ok.
>
> -1 (binding)
>
>
>
> On Fri, Jul 29, 2022 at 9:58 AM Stamatis Zampetakis 
> wrote:
>
> > Ubuntu 20.04.4 LTS, jdk1.8.0_261, Gradle wrapper, Gradle 7.4.2
> >
> >  * Checked checksums KO
> >  * Went over release note OK (left minor comments in the draft PR)
> >
> > $ sha512sum -c apache-calcite-1.31.0-src.tar.gz.sha512
> > apache-calcite-1.31.0-src.tar.gz: FAILED
> > sha512sum: WARNING: 1 computed checksum did NOT match
> >
> > $ sha512sum apache-calcite-1.31.0-src.tar.gz
> >
> >
> 9495f28e2c16ce6d5905a0b19b75e856e9a81e31c0252e8f6afed79c40ec88f71ecd708d90a63a1e5815a95dedfab56ebfa7e81851b3153833736447100a8f47
> >  apache-calcite-1.31.0-src.tar.gz
> >
> > -1 (binding)
> >
> > On Thu, Jul 28, 2022 at 6:40 PM Andrei Sereda  wrote:
> >
> > > Hi all,
> > >
> > > I have created a build for Apache Calcite 1.31.0, release
> > > candidate 1.
> > >
> > > Thanks to everyone who has contributed to this release.
> > >
> > > You can read the release notes here:
> > >
> > >
> >
> https://github.com/apache/calcite/blob/calcite-1.31.0-rc1/site/_docs/history.md
> > >
> > > The commit to be voted upon:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=4912aabe66fa06a30ea688c4bc2bf06dc05ee677
> > >
> > > Its hash is 4912aabe66fa06a30ea688c4bc2bf06dc05ee677
> > >
> > > Tag:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=calcite.git;a=tag;h=refs/tags/calcite-1.31.0-rc1
> > >
> > > The artifacts to be voted on are located here:
> > >
> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.31.0-rc1
> > > (revision 56015)
> > >
> > > The hashes of the artifacts are as follows:
> > >
> > >
> >
> 527e699857958b9d98e733059bd67ca6fc42e75238074dec65cc86caa8f5ae176e269d9ac478754ad206ea2336289a8f40f37ee86818130b37b53a53ee79bb2c
> > > *apache-calcite-1.31.0-src.tar.gz
> > >
> > > A staged Maven repository is available for review at:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecalcite-1168/org/apache/calcite/
> > >
> > > Release artifacts are signed with the following key:
> > > https://people.apache.org/keys/committer/sereda.asc
> > > https://www.apache.org/dist/calcite/KEYS
> > >
> > > To create the jars and test Apache Calcite: "gradle build"
> > > (requires an appropriate Gradle/JDK installation)
> > >
> > > Please vote on releasing this package as Apache Calcite 1.31.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.31.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 (non-binding)
> > >
> >
>


[CANCELLED] Release Apache Calcite 1.31.0 (release candidate 0)

2022-07-28 Thread Andrei Sereda
Hello,

Due to some issues detected with RC0 we have decided to prepare a new
candidate RC1.

The voting thread for RC0 is therefore closed.

Please follow communications on RC1 thread.

Regards,
Andrei.


Re: [VOTE] Release Apache Calcite 1.31.0 (release candidate 0)

2022-07-28 Thread Andrei Sereda
I have started a separate thread for RC1.

Among fixes that have been discussed previously, it also includes new
Avatica version 1.22: CALCITE-5221

On Tue, Jul 26, 2022 at 6:33 PM Andrei Sereda  wrote:

> Hello,
>
> Thanks for the detailed feedback.
>
> Regarding differences between git and src releases (empty folders reported
> by Stamatis) it is indeed a stale state of my branch. It is the main reason
> I'd like to make a clean (RC1) release candidate.
>
> Some answers to Julian's notes:
>
> > 1. It's strange that the release notes contain a blank section for
> 1.32 already. Probably better to add that section only after the
> release.
>
> 1.32 history section is being added as a jekyll comment and is not visible
> on the public site.  It is done to help the next RM. When I started a draft
> for history notes, a similar section was already prepared for 1.31.
>
> Agree that it is better to add if after the release.
>
>
> > 2. It would be useful if the breaking changes section said what about
> > CALCITE-4936 was breaking (In the bug, Statmatis wrote "Old behavior:
> > The Project operator is transformed into Calc. New behavior: The
> > Project operator is not transformed and the rule becomes NOOP.")
>
> Thanks. Will update the notes.
>
> > 4. It's ironic that the boilerplate has changed from  "Contributors to
> > this release" in 1.30 to "Thanks to all contributors (in alphabetical
> > order)" in this release and yet the list of contributors is not in
> > alphabetical order.
>
> Thanks for pointing it out.
>
>
> > 5. The build gives some scary warnings. We should fix these shortly.
>
> I will check if it is easily fixable.
>
>
> Overall I'm inclined to create RC1 mainly because of issues reported by
> Stamatis. Let me know if you agree.
>
> Thanks,
> Andrei.
>
> On Mon, Jul 25, 2022 at 8:22 PM Julian Hyde  wrote:
>
>> Andrei, Thank you for being release manager!
>>
>> Downloaded, checked signatures & checksums, LICENSE, NOTICE, howto.md;
>> compiled and ran tests using OpenJDK 18 and Gradle-7.4.2 on Ubuntu
>> Linux.
>>
>> My vote is 0 (binding) due to the arrow and .mvn directories noted by
>> Stamatis. I will change my vote to +1 if we have an explanation of why
>> these files exist and a plan to prevent them in future RCs.
>>
>> Julian
>>
>>
>> Notes:
>>
>> 1. It's strange that the release notes contain a blank section for
>> 1.32 already. Probably better to add that section only after the
>> release.
>>
>> 2. It would be useful if the breaking changes section said what about
>> CALCITE-4936 was breaking (In the bug, Statmatis wrote "Old behavior:
>> The Project operator is transformed into Calc. New behavior: The
>> Project operator is not transformed and the rule becomes NOOP.")
>>
>> 3. Andrei, you should have added yourself ("Andrei Sereda (release
>> manager)") to the list of contributors.
>>
>> 4. It's ironic that the boilerplate has changed from  "Contributors to
>> this release" in 1.30 to "Thanks to all contributors (in alphabetical
>> order)" in this release and yet the list of contributors is not in
>> alphabetical order.
>>
>> 5. The build gives some scary warnings. We should fix these shortly.
>>
>> > Configure project :buildSrc
>> Could not load entry 7b753dfea6780c3d32cd7106d24999f8 from remote
>> build cache: Bucket 'calcite-gradle-cache' not found
>>
>> > Task :buildSrc:buildext:compileKotlin
>> 'compileJava' task (current target is 18) and 'compileKotlin' task
>> (current target is 1.8) jvm target compatibility should be set to the
>> same Java version.
>>
>> > Task :buildSrc:javacc:compileKotlin
>> 'compileJava' task (current target is 18) and 'compileKotlin' task
>> (current target is 1.8) jvm target compatibility should be set to the
>> same Java version.
>>
>> w:
>> /tmp/apache-calcite-1.31.0-src/buildSrc/subprojects/javacc/src/main/kotlin/org/apache/calcite/buildtools/javacc/JavaCCTask.kt:
>> (66, 13): 'setter for main: String?' is deprecated. Deprecated in Java
>>
>> > Task :buildSrc:fmpp:compileKotlin
>> 'compileJava' task (current target is 18) and 'compileKotlin' task
>> (current target is 1.8) jvm target compatibility should be set to the
>> same Java version.
>>
>> On Mon, Jul 25, 2022 at 9:07 AM Stamatis Zampetakis 
>> wrote:
>> >
>> > Ubuntu 20.04.4 LTS, jdk1.8.0_261, Gradle wrapper, Gradle 7.4.2
>> >
>> >  * Checked signatures an

[VOTE] Release Apache Calcite 1.31.0 (release candidate 1)

2022-07-28 Thread Andrei Sereda
Hi all,

I have created a build for Apache Calcite 1.31.0, release
candidate 1.

Thanks to everyone who has contributed to this release.

You can read the release notes here:
https://github.com/apache/calcite/blob/calcite-1.31.0-rc1/site/_docs/history.md

The commit to be voted upon:
https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=4912aabe66fa06a30ea688c4bc2bf06dc05ee677

Its hash is 4912aabe66fa06a30ea688c4bc2bf06dc05ee677

Tag:
https://gitbox.apache.org/repos/asf?p=calcite.git;a=tag;h=refs/tags/calcite-1.31.0-rc1

The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.31.0-rc1
(revision 56015)

The hashes of the artifacts are as follows:
527e699857958b9d98e733059bd67ca6fc42e75238074dec65cc86caa8f5ae176e269d9ac478754ad206ea2336289a8f40f37ee86818130b37b53a53ee79bb2c
*apache-calcite-1.31.0-src.tar.gz

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1168/org/apache/calcite/

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/sereda.asc
https://www.apache.org/dist/calcite/KEYS

To create the jars and test Apache Calcite: "gradle build"
(requires an appropriate Gradle/JDK installation)

Please vote on releasing this package as Apache Calcite 1.31.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.31.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 (non-binding)


Re: [VOTE] Release Apache Calcite 1.31.0 (release candidate 0)

2022-07-26 Thread Andrei Sereda
Hello,

Thanks for the detailed feedback.

Regarding differences between git and src releases (empty folders reported
by Stamatis) it is indeed a stale state of my branch. It is the main reason
I'd like to make a clean (RC1) release candidate.

Some answers to Julian's notes:

> 1. It's strange that the release notes contain a blank section for
1.32 already. Probably better to add that section only after the
release.

1.32 history section is being added as a jekyll comment and is not visible
on the public site.  It is done to help the next RM. When I started a draft
for history notes, a similar section was already prepared for 1.31.

Agree that it is better to add if after the release.


> 2. It would be useful if the breaking changes section said what about
> CALCITE-4936 was breaking (In the bug, Statmatis wrote "Old behavior:
> The Project operator is transformed into Calc. New behavior: The
> Project operator is not transformed and the rule becomes NOOP.")

Thanks. Will update the notes.

> 4. It's ironic that the boilerplate has changed from  "Contributors to
> this release" in 1.30 to "Thanks to all contributors (in alphabetical
> order)" in this release and yet the list of contributors is not in
> alphabetical order.

Thanks for pointing it out.


> 5. The build gives some scary warnings. We should fix these shortly.

I will check if it is easily fixable.


Overall I'm inclined to create RC1 mainly because of issues reported by
Stamatis. Let me know if you agree.

Thanks,
Andrei.

On Mon, Jul 25, 2022 at 8:22 PM Julian Hyde  wrote:

> Andrei, Thank you for being release manager!
>
> Downloaded, checked signatures & checksums, LICENSE, NOTICE, howto.md;
> compiled and ran tests using OpenJDK 18 and Gradle-7.4.2 on Ubuntu
> Linux.
>
> My vote is 0 (binding) due to the arrow and .mvn directories noted by
> Stamatis. I will change my vote to +1 if we have an explanation of why
> these files exist and a plan to prevent them in future RCs.
>
> Julian
>
>
> Notes:
>
> 1. It's strange that the release notes contain a blank section for
> 1.32 already. Probably better to add that section only after the
> release.
>
> 2. It would be useful if the breaking changes section said what about
> CALCITE-4936 was breaking (In the bug, Statmatis wrote "Old behavior:
> The Project operator is transformed into Calc. New behavior: The
> Project operator is not transformed and the rule becomes NOOP.")
>
> 3. Andrei, you should have added yourself ("Andrei Sereda (release
> manager)") to the list of contributors.
>
> 4. It's ironic that the boilerplate has changed from  "Contributors to
> this release" in 1.30 to "Thanks to all contributors (in alphabetical
> order)" in this release and yet the list of contributors is not in
> alphabetical order.
>
> 5. The build gives some scary warnings. We should fix these shortly.
>
> > Configure project :buildSrc
> Could not load entry 7b753dfea6780c3d32cd7106d24999f8 from remote
> build cache: Bucket 'calcite-gradle-cache' not found
>
> > Task :buildSrc:buildext:compileKotlin
> 'compileJava' task (current target is 18) and 'compileKotlin' task
> (current target is 1.8) jvm target compatibility should be set to the
> same Java version.
>
> > Task :buildSrc:javacc:compileKotlin
> 'compileJava' task (current target is 18) and 'compileKotlin' task
> (current target is 1.8) jvm target compatibility should be set to the
> same Java version.
>
> w:
> /tmp/apache-calcite-1.31.0-src/buildSrc/subprojects/javacc/src/main/kotlin/org/apache/calcite/buildtools/javacc/JavaCCTask.kt:
> (66, 13): 'setter for main: String?' is deprecated. Deprecated in Java
>
> > Task :buildSrc:fmpp:compileKotlin
> 'compileJava' task (current target is 18) and 'compileKotlin' task
> (current target is 1.8) jvm target compatibility should be set to the
> same Java version.
>
> On Mon, Jul 25, 2022 at 9:07 AM Stamatis Zampetakis 
> wrote:
> >
> > Ubuntu 20.04.4 LTS, jdk1.8.0_261, Gradle wrapper, Gradle 7.4.2
> >
> >  * Checked signatures and checksums OK
> >  * Went over release note OK (left some comments in the draft PR)
> >  * Built from git tag and run tests (./gradlew clean build) OK
> >  * Built from source artifacts and run unit tests + slow tests OK
> >  * Checked diff between git repo and release sources KO
> >
> > Comparing the contents between the git repo and the release sources I
> found
> > that the (RC0) sources contain two (empty) directories (i.e., arrow,
> .mvn)
> > that shouldn't be there.
> > I guess there was some kind of stale state in the calcite directory when
> > preparing the RC. The command that I used to compare th

[VOTE] Release Apache Calcite 1.31.0 (release candidate 0)

2022-07-22 Thread Andrei Sereda
Hi all,

I have created a build for Apache Calcite 1.31.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/calcite-1.31.0-rc0/site/_docs/history.md

The commit to be voted upon:
https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=c416e109460d8e439078206a48057b504b6bb08b

Its hash is c416e109460d8e439078206a48057b504b6bb08b

Tag:
https://gitbox.apache.org/repos/asf?p=calcite.git;a=tag;h=refs/tags/calcite-1.31.0-rc0

The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.31.0-rc0
(revision 55918)

The hashes of the artifacts are as follows:
527e699857958b9d98e733059bd67ca6fc42e75238074dec65cc86caa8f5ae176e269d9ac478754ad206ea2336289a8f40f37ee86818130b37b53a53ee79bb2c
*apache-calcite-1.31.0-src.tar.gz

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1166/org/apache/calcite/

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/sereda.asc
https://www.apache.org/dist/calcite/KEYS

To create the jars and test Apache Calcite: "gradle build"
(requires an appropriate Gradle/JDK installation)

Please vote on releasing this package as Apache Calcite 1.31.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.31.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 (non-binding)


Re: [DISCUSS] Towards Calcite 1.31.0

2022-07-22 Thread Andrei Sereda
It should be all good now.

My problem was that I use different accounts for github and gitbox.

For some reason the gradle release plugin was using github credentials (
asfGitSourceUsername property) and not nexus ones (asfNexusUsername) from
~/.gradle/gradle.properties. Maybe because of the pushRepositoryProvider
override ?



On Fri, Jul 22, 2022 at 10:47 PM Andrei Sereda  wrote:

> Thanks, Julian. I did include GITBOX in the prepare vote command.
>
> $ gradle  prepareVote -Prc=0 -Pasf -Pasf.git.pushRepositoryProvider=GITBOX
>
>
>
> On Fri, Jul 22, 2022 at 1:31 PM Julian Hyde  wrote:
>
>> Andrei, Are you perhaps running into
>> https://issues.apache.org/jira/browse/CALCITE-4856 ?
>>
>> On Fri, Jul 22, 2022 at 7:36 AM Andrei Sereda  wrote:
>> >
>> > Quick update.
>> >
>> > I've addressed all comments in the release notes PR.
>> >
>> > While tagging RC0, I've run into small issue with apache gitbox
>> > authorization (see below) but should be able to solve them (I've
>> released
>> > 1.25 in the past without problems with the new gradle process)
>> >
>> >
>> > > Task :pushRcTag
>> > Pushing tag to Git remote release-origin:
>> > https://gitbox.apache.org/repos/asf/calcite.git
>> >
>> > > Task :pushRcTag FAILED
>> >
>> > Build calcite FAILURE reason:
>> > Execution failed for task ':pushRcTag':
>> >* Caused by: org.eclipse.jgit.api.errors.TransportException:
>> > https://gitbox.apache.org/repos/asf/calcite.git
>> > <https://gitbox.apache.org/repos/asf/calcite.git>: not authorized*
>> > at
>> org.eclipse.jgit.api.PushCommand.call(PushCommand.java:180)
>> > at
>> >
>> com.github.vlsi.gradle.release.jgit.dsl.GitExtensionsKt.push(GitExtensions.kt:132)
>> > at
>> >
>> com.github.vlsi.gradle.release.GitPushTask$pushTag$1.invoke(GitPushTask.kt:54)
>> >
>> > On Thu, Jul 21, 2022 at 1:14 AM Andrei Sereda 
>> wrote:
>> >
>> > > Hi Julian,
>> > >
>> > > I think it is a great idea.
>> > >
>> > > Please take a look at proposed release notes:
>> > > https://github.com/apache/calcite/pull/2858
>> > >
>> > > Thanks,
>> > > Andrei.
>> > >
>> > >
>> > > On Wed, Jul 20, 2022 at 4:31 PM Julian Hyde 
>> > > wrote:
>> > >
>> > >> Andrei,
>> > >>
>> > >> One thing that has worked well is for the RM to create a PR with the
>> > >> release notes. People can then review the release notes, comment on
>> that
>> > >> PR, and add their own release notes. As RM you would not submit the
>> PR, but
>> > >> instead manually rebase onto the final RC.
>> > >>
>> > >> Julian
>> > >>
>> > >>
>> > >> > On Jul 19, 2022, at 6:44 PM, Andrei Sereda 
>> wrote:
>> > >> >
>> > >> > Hello,
>> > >> >
>> > >> > Anything specific you'd like to be added to the release notes of
>> 1.31 ?
>> > >> > If so, please provide a short summary as well as JIRA id.
>> > >> >
>> > >> >
>> > >> > Andrei.
>> > >> >
>> > >> > On Tue, Jul 12, 2022 at 10:07 PM Andrei Sereda 
>> > >> wrote:
>> > >> >
>> > >> >> Hi Julian,
>> > >> >>
>> > >> >>
>> > >> >>> Andrei, Are there any remaining blockers for 1.31?
>> > >> >> No blockers for 1.31. Any pending issues can be moved towards
>> 1.32.
>> > >> >>
>> > >> >>> Can we proceed with an RC0?
>> > >> >>
>> > >> >> Yes, I'll start the release very soon.
>> > >> >>
>> > >> >> Thanks for fixing the regression.
>> > >> >>
>> > >> >> Andrei.
>> > >> >>
>> > >> >>
>> > >> >> On Tue, Jul 12, 2022 at 4:35 PM Julian Hyde <
>> jhyde.apa...@gmail.com>
>> > >> >> wrote:
>> > >> >>
>> > >> >>> I merged https://issues.apache.org/jira/browse/CALCITE-5194 <
>> > >> >>> https://issues.apache.org/jira/browse/CALCITE-5194>, the fix
>>

Re: [DISCUSS] Towards Calcite 1.31.0

2022-07-22 Thread Andrei Sereda
Thanks, Julian. I did include GITBOX in the prepare vote command.

$ gradle  prepareVote -Prc=0 -Pasf -Pasf.git.pushRepositoryProvider=GITBOX



On Fri, Jul 22, 2022 at 1:31 PM Julian Hyde  wrote:

> Andrei, Are you perhaps running into
> https://issues.apache.org/jira/browse/CALCITE-4856 ?
>
> On Fri, Jul 22, 2022 at 7:36 AM Andrei Sereda  wrote:
> >
> > Quick update.
> >
> > I've addressed all comments in the release notes PR.
> >
> > While tagging RC0, I've run into small issue with apache gitbox
> > authorization (see below) but should be able to solve them (I've released
> > 1.25 in the past without problems with the new gradle process)
> >
> >
> > > Task :pushRcTag
> > Pushing tag to Git remote release-origin:
> > https://gitbox.apache.org/repos/asf/calcite.git
> >
> > > Task :pushRcTag FAILED
> >
> > Build calcite FAILURE reason:
> > Execution failed for task ':pushRcTag':
> >* Caused by: org.eclipse.jgit.api.errors.TransportException:
> > https://gitbox.apache.org/repos/asf/calcite.git
> > <https://gitbox.apache.org/repos/asf/calcite.git>: not authorized*
> > at
> org.eclipse.jgit.api.PushCommand.call(PushCommand.java:180)
> > at
> >
> com.github.vlsi.gradle.release.jgit.dsl.GitExtensionsKt.push(GitExtensions.kt:132)
> > at
> >
> com.github.vlsi.gradle.release.GitPushTask$pushTag$1.invoke(GitPushTask.kt:54)
> >
> > On Thu, Jul 21, 2022 at 1:14 AM Andrei Sereda  wrote:
> >
> > > Hi Julian,
> > >
> > > I think it is a great idea.
> > >
> > > Please take a look at proposed release notes:
> > > https://github.com/apache/calcite/pull/2858
> > >
> > > Thanks,
> > > Andrei.
> > >
> > >
> > > On Wed, Jul 20, 2022 at 4:31 PM Julian Hyde 
> > > wrote:
> > >
> > >> Andrei,
> > >>
> > >> One thing that has worked well is for the RM to create a PR with the
> > >> release notes. People can then review the release notes, comment on
> that
> > >> PR, and add their own release notes. As RM you would not submit the
> PR, but
> > >> instead manually rebase onto the final RC.
> > >>
> > >> Julian
> > >>
> > >>
> > >> > On Jul 19, 2022, at 6:44 PM, Andrei Sereda 
> wrote:
> > >> >
> > >> > Hello,
> > >> >
> > >> > Anything specific you'd like to be added to the release notes of
> 1.31 ?
> > >> > If so, please provide a short summary as well as JIRA id.
> > >> >
> > >> >
> > >> > Andrei.
> > >> >
> > >> > On Tue, Jul 12, 2022 at 10:07 PM Andrei Sereda 
> > >> wrote:
> > >> >
> > >> >> Hi Julian,
> > >> >>
> > >> >>
> > >> >>> Andrei, Are there any remaining blockers for 1.31?
> > >> >> No blockers for 1.31. Any pending issues can be moved towards 1.32.
> > >> >>
> > >> >>> Can we proceed with an RC0?
> > >> >>
> > >> >> Yes, I'll start the release very soon.
> > >> >>
> > >> >> Thanks for fixing the regression.
> > >> >>
> > >> >> Andrei.
> > >> >>
> > >> >>
> > >> >> On Tue, Jul 12, 2022 at 4:35 PM Julian Hyde <
> jhyde.apa...@gmail.com>
> > >> >> wrote:
> > >> >>
> > >> >>> I merged https://issues.apache.org/jira/browse/CALCITE-5194 <
> > >> >>> https://issues.apache.org/jira/browse/CALCITE-5194>, the fix for
> the
> > >> >>> regression due to
> https://issues.apache.org/jira/browse/CALCITE-35 <
> > >> >>> https://issues.apache.org/jira/browse/CALCITE-35>, yesterday.
> > >> >>>
> > >> >>> Andrei, Are there any remaining blockers for 1.31? Can we proceed
> > >> with an
> > >> >>> RC0?
> > >> >>>
> > >> >>> Julian
> > >> >>>
> > >> >>>
> > >> >>>> On Jun 21, 2022, at 11:29 PM, Yanjing Wang <
> > >> zhuangzixiao...@gmail.com>
> > >> >>> wrote:
> > >> >>>>
> > >> >>>> Thanks Andrei, now there is nobody to review 

Re: [DISCUSS] Towards Calcite 1.31.0

2022-07-22 Thread Andrei Sereda
Quick update.

I've addressed all comments in the release notes PR.

While tagging RC0, I've run into small issue with apache gitbox
authorization (see below) but should be able to solve them (I've released
1.25 in the past without problems with the new gradle process)


> Task :pushRcTag
Pushing tag to Git remote release-origin:
https://gitbox.apache.org/repos/asf/calcite.git

> Task :pushRcTag FAILED

Build calcite FAILURE reason:
Execution failed for task ':pushRcTag':
   * Caused by: org.eclipse.jgit.api.errors.TransportException:
https://gitbox.apache.org/repos/asf/calcite.git
<https://gitbox.apache.org/repos/asf/calcite.git>: not authorized*
at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:180)
at
com.github.vlsi.gradle.release.jgit.dsl.GitExtensionsKt.push(GitExtensions.kt:132)
at
com.github.vlsi.gradle.release.GitPushTask$pushTag$1.invoke(GitPushTask.kt:54)

On Thu, Jul 21, 2022 at 1:14 AM Andrei Sereda  wrote:

> Hi Julian,
>
> I think it is a great idea.
>
> Please take a look at proposed release notes:
> https://github.com/apache/calcite/pull/2858
>
> Thanks,
> Andrei.
>
>
> On Wed, Jul 20, 2022 at 4:31 PM Julian Hyde 
> wrote:
>
>> Andrei,
>>
>> One thing that has worked well is for the RM to create a PR with the
>> release notes. People can then review the release notes, comment on that
>> PR, and add their own release notes. As RM you would not submit the PR, but
>> instead manually rebase onto the final RC.
>>
>> Julian
>>
>>
>> > On Jul 19, 2022, at 6:44 PM, Andrei Sereda  wrote:
>> >
>> > Hello,
>> >
>> > Anything specific you'd like to be added to the release notes of 1.31 ?
>> > If so, please provide a short summary as well as JIRA id.
>> >
>> >
>> > Andrei.
>> >
>> > On Tue, Jul 12, 2022 at 10:07 PM Andrei Sereda 
>> wrote:
>> >
>> >> Hi Julian,
>> >>
>> >>
>> >>> Andrei, Are there any remaining blockers for 1.31?
>> >> No blockers for 1.31. Any pending issues can be moved towards 1.32.
>> >>
>> >>> Can we proceed with an RC0?
>> >>
>> >> Yes, I'll start the release very soon.
>> >>
>> >> Thanks for fixing the regression.
>> >>
>> >> Andrei.
>> >>
>> >>
>> >> On Tue, Jul 12, 2022 at 4:35 PM Julian Hyde 
>> >> wrote:
>> >>
>> >>> I merged https://issues.apache.org/jira/browse/CALCITE-5194 <
>> >>> https://issues.apache.org/jira/browse/CALCITE-5194>, the fix for the
>> >>> regression due to https://issues.apache.org/jira/browse/CALCITE-35 <
>> >>> https://issues.apache.org/jira/browse/CALCITE-35>, yesterday.
>> >>>
>> >>> Andrei, Are there any remaining blockers for 1.31? Can we proceed
>> with an
>> >>> RC0?
>> >>>
>> >>> Julian
>> >>>
>> >>>
>> >>>> On Jun 21, 2022, at 11:29 PM, Yanjing Wang <
>> zhuangzixiao...@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Thanks Andrei, now there is nobody to review these PRs, It's ok to
>> >>> change
>> >>>> to 1.32,I think pr-2838 <https://github.com/apache/calcite/pull/2838
>> >
>> >>> for
>> >>>> CALCITE-5045 <https://issues.apache.org/jira/browse/CALCITE-5045>
>> >>> should be
>> >>>> merged before 1.31, because it's simple and Yingyu Wang  encountered
>> >>> this
>> >>>> problem also.
>> >>>>
>> >>>> Andrei Sereda  于2022年6月22日周三 10:06写道:
>> >>>>
>> >>>>> Julian, how much time do you think is necessary to fix CALCITE-35
>> >>>>> regression ?
>> >>>>>
>> >>>>> Yanjing, I see some discussions/attempts in JIRA/github to review
>> the
>> >>> PRs.
>> >>>>> Do you think it can still be reviewed and merged before 1.31 ?
>> >>>>>
>> >>>>> Viliam (and Julian), thanks for fixing (and merging) CALCITE-5157
>> >>>>>
>> >>>>> Dmitry (and Stamatis / Ruben), thanks for fixing (and merging)
>> >>>>> CALCITE-5134.
>> >>>>> As I understand CALCITE-5127 is delayed until 1.32 ?
>> >>>>>
>> >>>>>
>> >>>>

Re: [DISCUSS] Towards Calcite 1.31.0

2022-07-20 Thread Andrei Sereda
Hi Julian,

I think it is a great idea.

Please take a look at proposed release notes:
https://github.com/apache/calcite/pull/2858

Thanks,
Andrei.


On Wed, Jul 20, 2022 at 4:31 PM Julian Hyde  wrote:

> Andrei,
>
> One thing that has worked well is for the RM to create a PR with the
> release notes. People can then review the release notes, comment on that
> PR, and add their own release notes. As RM you would not submit the PR, but
> instead manually rebase onto the final RC.
>
> Julian
>
>
> > On Jul 19, 2022, at 6:44 PM, Andrei Sereda  wrote:
> >
> > Hello,
> >
> > Anything specific you'd like to be added to the release notes of 1.31 ?
> > If so, please provide a short summary as well as JIRA id.
> >
> >
> > Andrei.
> >
> > On Tue, Jul 12, 2022 at 10:07 PM Andrei Sereda 
> wrote:
> >
> >> Hi Julian,
> >>
> >>
> >>> Andrei, Are there any remaining blockers for 1.31?
> >> No blockers for 1.31. Any pending issues can be moved towards 1.32.
> >>
> >>> Can we proceed with an RC0?
> >>
> >> Yes, I'll start the release very soon.
> >>
> >> Thanks for fixing the regression.
> >>
> >> Andrei.
> >>
> >>
> >> On Tue, Jul 12, 2022 at 4:35 PM Julian Hyde 
> >> wrote:
> >>
> >>> I merged https://issues.apache.org/jira/browse/CALCITE-5194 <
> >>> https://issues.apache.org/jira/browse/CALCITE-5194>, the fix for the
> >>> regression due to https://issues.apache.org/jira/browse/CALCITE-35 <
> >>> https://issues.apache.org/jira/browse/CALCITE-35>, yesterday.
> >>>
> >>> Andrei, Are there any remaining blockers for 1.31? Can we proceed with
> an
> >>> RC0?
> >>>
> >>> Julian
> >>>
> >>>
> >>>> On Jun 21, 2022, at 11:29 PM, Yanjing Wang  >
> >>> wrote:
> >>>>
> >>>> Thanks Andrei, now there is nobody to review these PRs, It's ok to
> >>> change
> >>>> to 1.32,I think pr-2838 <https://github.com/apache/calcite/pull/2838>
> >>> for
> >>>> CALCITE-5045 <https://issues.apache.org/jira/browse/CALCITE-5045>
> >>> should be
> >>>> merged before 1.31, because it's simple and Yingyu Wang  encountered
> >>> this
> >>>> problem also.
> >>>>
> >>>> Andrei Sereda  于2022年6月22日周三 10:06写道:
> >>>>
> >>>>> Julian, how much time do you think is necessary to fix CALCITE-35
> >>>>> regression ?
> >>>>>
> >>>>> Yanjing, I see some discussions/attempts in JIRA/github to review the
> >>> PRs.
> >>>>> Do you think it can still be reviewed and merged before 1.31 ?
> >>>>>
> >>>>> Viliam (and Julian), thanks for fixing (and merging) CALCITE-5157
> >>>>>
> >>>>> Dmitry (and Stamatis / Ruben), thanks for fixing (and merging)
> >>>>> CALCITE-5134.
> >>>>> As I understand CALCITE-5127 is delayed until 1.32 ?
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Jun 21, 2022 at 2:57 AM Julian Hyde 
> >>>>> wrote:
> >>>>>
> >>>>>> I agree that it’s a regression, and caused by my CALCITE-35 change.
> >>> I’ve
> >>>>>> assigned the bug to myself. I’m not sure I have time to fix it this
> >>> week,
> >>>>>> so we can back out my change if necessary to get the release out on
> >>>>>> schedule. If someone else can fix it I would be grateful.
> >>>>>>
> >>>>>>
> >>>>>>> On Jun 19, 2022, at 2:26 AM, Vova Vysotskyi 
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I have found the following regression while verifying the new
> release
> >>>>> to
> >>>>>> work with Apache Drill:
> >>>>> https://issues.apache.org/jira/browse/CALCITE-5194
> >>>>>> .
> >>>>>>> This issue appeared after changes for
> >>>>>> https://issues.apache.org/jira/browse/CALCITE-35.
> >>>>>>> Since it is a regression, I suggest treating it as a blocker for
> the
> >>>>>> upcoming release.

Re: [DISCUSS] Towards Calcite 1.31.0

2022-07-19 Thread Andrei Sereda
Hello,

Anything specific you'd like to be added to the release notes of 1.31 ?
If so, please provide a short summary as well as JIRA id.


Andrei.

On Tue, Jul 12, 2022 at 10:07 PM Andrei Sereda  wrote:

> Hi Julian,
>
>
> > Andrei, Are there any remaining blockers for 1.31?
> No blockers for 1.31. Any pending issues can be moved towards 1.32.
>
> > Can we proceed with an RC0?
>
> Yes, I'll start the release very soon.
>
> Thanks for fixing the regression.
>
> Andrei.
>
>
> On Tue, Jul 12, 2022 at 4:35 PM Julian Hyde 
> wrote:
>
>> I merged https://issues.apache.org/jira/browse/CALCITE-5194 <
>> https://issues.apache.org/jira/browse/CALCITE-5194>, the fix for the
>> regression due to https://issues.apache.org/jira/browse/CALCITE-35 <
>> https://issues.apache.org/jira/browse/CALCITE-35>, yesterday.
>>
>> Andrei, Are there any remaining blockers for 1.31? Can we proceed with an
>> RC0?
>>
>> Julian
>>
>>
>> > On Jun 21, 2022, at 11:29 PM, Yanjing Wang 
>> wrote:
>> >
>> > Thanks Andrei, now there is nobody to review these PRs, It's ok to
>> change
>> > to 1.32,I think pr-2838 <https://github.com/apache/calcite/pull/2838>
>> for
>> > CALCITE-5045 <https://issues.apache.org/jira/browse/CALCITE-5045>
>> should be
>> > merged before 1.31, because it's simple and Yingyu Wang  encountered
>> this
>> > problem also.
>> >
>> > Andrei Sereda  于2022年6月22日周三 10:06写道:
>> >
>> >> Julian, how much time do you think is necessary to fix CALCITE-35
>> >> regression ?
>> >>
>> >> Yanjing, I see some discussions/attempts in JIRA/github to review the
>> PRs.
>> >> Do you think it can still be reviewed and merged before 1.31 ?
>> >>
>> >> Viliam (and Julian), thanks for fixing (and merging) CALCITE-5157
>> >>
>> >> Dmitry (and Stamatis / Ruben), thanks for fixing (and merging)
>> >> CALCITE-5134.
>> >> As I understand CALCITE-5127 is delayed until 1.32 ?
>> >>
>> >>
>> >>
>> >> On Tue, Jun 21, 2022 at 2:57 AM Julian Hyde 
>> >> wrote:
>> >>
>> >>> I agree that it’s a regression, and caused by my CALCITE-35 change.
>> I’ve
>> >>> assigned the bug to myself. I’m not sure I have time to fix it this
>> week,
>> >>> so we can back out my change if necessary to get the release out on
>> >>> schedule. If someone else can fix it I would be grateful.
>> >>>
>> >>>
>> >>>> On Jun 19, 2022, at 2:26 AM, Vova Vysotskyi 
>> >>> wrote:
>> >>>>
>> >>>> Hello,
>> >>>>
>> >>>> I have found the following regression while verifying the new release
>> >> to
>> >>> work with Apache Drill:
>> >> https://issues.apache.org/jira/browse/CALCITE-5194
>> >>> .
>> >>>> This issue appeared after changes for
>> >>> https://issues.apache.org/jira/browse/CALCITE-35.
>> >>>> Since it is a regression, I suggest treating it as a blocker for the
>> >>> upcoming release.
>> >>>>
>> >>>> Kind regards,
>> >>>> Volodymyr Vysotskyi
>> >>>>
>> >>>> On 2022/06/16 06:38:45 Viliam Durina wrote:
>> >>>>> I'll try to work on comments in CALCITE-5157
>> >>>>> <https://issues.apache.org/jira/browse/CALCITE-5157> today
>> >>>>>
>> >>>>> On Wed, 15 Jun 2022 at 07:30, Yanjing Wang <
>> zhuangzixiao...@gmail.com
>> >>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi Andrei,
>> >>>>>> The followings need review process to merge.
>> >>>>>> https://issues.apache.org/jira/browse/CALCITE-4512
>> >>>>>> https://issues.apache.org/jira/browse/CALCITE-5045
>> >>>>>> https://issues.apache.org/jira/browse/CALCITE-5043
>> >>>>>> https://issues.apache.org/jira/browse/CALCITE-4987
>> >>>>>> It would be great if they were fixed in this release.
>> >>>>>>
>> >>>>>> Dmitry Sysolyatin  于2022年6月14日周二 17:18写道:
>> >>>>>>
>> >>>>>>> Hi!
>> >>>>>>> It would be good to merge:
>> &g

Calcite Release 1.31 started

2022-07-19 Thread Andrei Sereda
Hello,

I'm starting the Calcite 1.31 release. Main branch will be frozen until
completion.

Please avoid committing anything to main until further notice.

Andrei.


Re: [DISCUSS] Towards Calcite 1.31.0

2022-07-12 Thread Andrei Sereda
Hi Julian,


> Andrei, Are there any remaining blockers for 1.31?
No blockers for 1.31. Any pending issues can be moved towards 1.32.

> Can we proceed with an RC0?

Yes, I'll start the release very soon.

Thanks for fixing the regression.

Andrei.


On Tue, Jul 12, 2022 at 4:35 PM Julian Hyde  wrote:

> I merged https://issues.apache.org/jira/browse/CALCITE-5194 <
> https://issues.apache.org/jira/browse/CALCITE-5194>, the fix for the
> regression due to https://issues.apache.org/jira/browse/CALCITE-35 <
> https://issues.apache.org/jira/browse/CALCITE-35>, yesterday.
>
> Andrei, Are there any remaining blockers for 1.31? Can we proceed with an
> RC0?
>
> Julian
>
>
> > On Jun 21, 2022, at 11:29 PM, Yanjing Wang 
> wrote:
> >
> > Thanks Andrei, now there is nobody to review these PRs, It's ok to change
> > to 1.32,I think pr-2838 <https://github.com/apache/calcite/pull/2838>
> for
> > CALCITE-5045 <https://issues.apache.org/jira/browse/CALCITE-5045>
> should be
> > merged before 1.31, because it's simple and Yingyu Wang  encountered this
> > problem also.
> >
> > Andrei Sereda  于2022年6月22日周三 10:06写道:
> >
> >> Julian, how much time do you think is necessary to fix CALCITE-35
> >> regression ?
> >>
> >> Yanjing, I see some discussions/attempts in JIRA/github to review the
> PRs.
> >> Do you think it can still be reviewed and merged before 1.31 ?
> >>
> >> Viliam (and Julian), thanks for fixing (and merging) CALCITE-5157
> >>
> >> Dmitry (and Stamatis / Ruben), thanks for fixing (and merging)
> >> CALCITE-5134.
> >> As I understand CALCITE-5127 is delayed until 1.32 ?
> >>
> >>
> >>
> >> On Tue, Jun 21, 2022 at 2:57 AM Julian Hyde 
> >> wrote:
> >>
> >>> I agree that it’s a regression, and caused by my CALCITE-35 change.
> I’ve
> >>> assigned the bug to myself. I’m not sure I have time to fix it this
> week,
> >>> so we can back out my change if necessary to get the release out on
> >>> schedule. If someone else can fix it I would be grateful.
> >>>
> >>>
> >>>> On Jun 19, 2022, at 2:26 AM, Vova Vysotskyi 
> >>> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> I have found the following regression while verifying the new release
> >> to
> >>> work with Apache Drill:
> >> https://issues.apache.org/jira/browse/CALCITE-5194
> >>> .
> >>>> This issue appeared after changes for
> >>> https://issues.apache.org/jira/browse/CALCITE-35.
> >>>> Since it is a regression, I suggest treating it as a blocker for the
> >>> upcoming release.
> >>>>
> >>>> Kind regards,
> >>>> Volodymyr Vysotskyi
> >>>>
> >>>> On 2022/06/16 06:38:45 Viliam Durina wrote:
> >>>>> I'll try to work on comments in CALCITE-5157
> >>>>> <https://issues.apache.org/jira/browse/CALCITE-5157> today
> >>>>>
> >>>>> On Wed, 15 Jun 2022 at 07:30, Yanjing Wang <
> zhuangzixiao...@gmail.com
> >>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi Andrei,
> >>>>>> The followings need review process to merge.
> >>>>>> https://issues.apache.org/jira/browse/CALCITE-4512
> >>>>>> https://issues.apache.org/jira/browse/CALCITE-5045
> >>>>>> https://issues.apache.org/jira/browse/CALCITE-5043
> >>>>>> https://issues.apache.org/jira/browse/CALCITE-4987
> >>>>>> It would be great if they were fixed in this release.
> >>>>>>
> >>>>>> Dmitry Sysolyatin  于2022年6月14日周二 17:18写道:
> >>>>>>
> >>>>>>> Hi!
> >>>>>>> It would be good to merge:
> >>>>>>> https://issues.apache.org/jira/browse/CALCITE-5134
> >>>>>>> https://issues.apache.org/jira/browse/CALCITE-5127
> >>>>>>>
> >>>>>>> Both of those issues are related to correct execution queries with
> >>>>>>> subqueries.
> >>>>>>>
> >>>>>>> On Tue, Jun 14, 2022 at 6:59 AM Andrei Sereda 
> >>> wrote:
> >>>>>>>
> >>>>>>>> Thanks to all who reviewed the PRs for 1.31 release.
> >>>>>>>>
> >>>>

Re: [DISCUSS] Towards Calcite 1.31.0

2022-06-21 Thread Andrei Sereda
Julian, how much time do you think is necessary to fix CALCITE-35
regression ?

Yanjing, I see some discussions/attempts in JIRA/github to review the PRs.
Do you think it can still be reviewed and merged before 1.31 ?

Viliam (and Julian), thanks for fixing (and merging) CALCITE-5157

Dmitry (and Stamatis / Ruben), thanks for fixing (and merging) CALCITE-5134.
As I understand CALCITE-5127 is delayed until 1.32 ?



On Tue, Jun 21, 2022 at 2:57 AM Julian Hyde  wrote:

> I agree that it’s a regression, and caused by my CALCITE-35 change. I’ve
> assigned the bug to myself. I’m not sure I have time to fix it this week,
> so we can back out my change if necessary to get the release out on
> schedule. If someone else can fix it I would be grateful.
>
>
> > On Jun 19, 2022, at 2:26 AM, Vova Vysotskyi 
> wrote:
> >
> > Hello,
> >
> > I have found the following regression while verifying the new release to
> work with Apache Drill: https://issues.apache.org/jira/browse/CALCITE-5194
> .
> > This issue appeared after changes for
> https://issues.apache.org/jira/browse/CALCITE-35.
> > Since it is a regression, I suggest treating it as a blocker for the
> upcoming release.
> >
> > Kind regards,
> > Volodymyr Vysotskyi
> >
> > On 2022/06/16 06:38:45 Viliam Durina wrote:
> >> I'll try to work on comments in CALCITE-5157
> >> <https://issues.apache.org/jira/browse/CALCITE-5157> today
> >>
> >> On Wed, 15 Jun 2022 at 07:30, Yanjing Wang 
> >> wrote:
> >>
> >>> Hi Andrei,
> >>> The followings need review process to merge.
> >>> https://issues.apache.org/jira/browse/CALCITE-4512
> >>> https://issues.apache.org/jira/browse/CALCITE-5045
> >>> https://issues.apache.org/jira/browse/CALCITE-5043
> >>> https://issues.apache.org/jira/browse/CALCITE-4987
> >>> It would be great if they were fixed in this release.
> >>>
> >>> Dmitry Sysolyatin  于2022年6月14日周二 17:18写道:
> >>>
> >>>> Hi!
> >>>> It would be good to merge:
> >>>> https://issues.apache.org/jira/browse/CALCITE-5134
> >>>> https://issues.apache.org/jira/browse/CALCITE-5127
> >>>>
> >>>> Both of those issues are related to correct execution queries with
> >>>> subqueries.
> >>>>
> >>>> On Tue, Jun 14, 2022 at 6:59 AM Andrei Sereda 
> wrote:
> >>>>
> >>>>> Thanks to all who reviewed the PRs for 1.31 release.
> >>>>>
> >>>>> There are about 16 issues remaining tagged for 1.31 (list
> >>>>> <
> >>>>>
> >>>>
> >>>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20fixVersion%20%3D%201.31.0%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20%22In%20Review%22%2C%20%22In%20Implementation%22)%20ORDER%20BY%20priority%20DESC
> >>>>>>
> >>>>> ).
> >>>>>
> >>>>> Please let me know which ones are important for this release (and
> I'll
> >>>>> wait) otherwise I'll re-tag those issues for next release 1.32.
> >>>>>
> >>>>> Regards,
> >>>>> Andrei.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Jun 13, 2022 at 1:05 PM Julian Hyde 
> >>>>> wrote:
> >>>>>
> >>>>>> I’m on vacation this week so don’t ask me to review PRs.
> >>>>>>
> >>>>>> It looks like we’re on course for an RC this week, and definitely
> >>> don’t
> >>>>>> wait for me. Maybe we can get a few more PRs merged before then, and
> >>>> move
> >>>>>> the rest to 1.32 (or clear the fix version if the person who agreed
> >>> to
> >>>>> fix
> >>>>>> the bug has not responded).
> >>>>>>
> >>>>>> Julian
> >>>>>>
> >>>>>>
> >>>>>>> On Jun 4, 2022, at 2:17 PM, Andrei Sereda 
> >>> wrote:
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I have created a JIRA filter
> >>>>>>> <
> >>>>>>
> >>>>>
> >>>>
> >>>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20fixVersion%20%3D%201.31.0%20AND%

Re: [DISCUSS] Towards Calcite 1.31.0

2022-06-13 Thread Andrei Sereda
Thanks to all who reviewed the PRs for 1.31 release.

There are about 16 issues remaining tagged for 1.31 (list
<https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20fixVersion%20%3D%201.31.0%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20%22In%20Review%22%2C%20%22In%20Implementation%22)%20ORDER%20BY%20priority%20DESC>
).

Please let me know which ones are important for this release (and I'll
wait) otherwise I'll re-tag those issues for next release 1.32.

Regards,
Andrei.



On Mon, Jun 13, 2022 at 1:05 PM Julian Hyde  wrote:

> I’m on vacation this week so don’t ask me to review PRs.
>
> It looks like we’re on course for an RC this week, and definitely don’t
> wait for me. Maybe we can get a few more PRs merged before then, and move
> the rest to 1.32 (or clear the fix version if the person who agreed to fix
> the bug has not responded).
>
> Julian
>
>
> > On Jun 4, 2022, at 2:17 PM, Andrei Sereda  wrote:
> >
> > Hello,
> >
> > I have created a JIRA filter
> > <
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20fixVersion%20%3D%201.31.0%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20%22In%20Review%22%2C%20%22In%20Implementation%22)%20ORDER%20BY%20priority%20DESC
> >
> > for 1.31 release. There are currently 25 unresolved issues (planned for
> > 1.31).
> >
> > If you are familiar with some of the JIRA tickets can you please review
> the
> > PRs and resolve the ticket ?
> >
> > The plan is to have an RC in 1-2 weeks.
> >
> > Regards,
> > Andrei.
> >
> >
> > On Sat, Jun 4, 2022 at 6:13 AM Vova Vysotskyi 
> wrote:
> >
> >> Hello,
> >>
> >> Could we also include https://github.com/apache/calcite/pull/2305 into
> >> this release?
> >> I have rebased it onto the latest master and fixed all merge conflicts.
> >>
> >> Kind regards,
> >> Volodymyr Vysotskyi
> >>
> >> On 2022/05/30 17:57:28 Julian Hyde wrote:
> >>> Viliam, I marked the Jira case ‘fix in 1.31’ so that someone will at
> >> least review your PR.
> >>>
> >>>> On May 30, 2022, at 7:09 AM, Viliam Durina
> >>  wrote:
> >>>>
> >>>> Our PR is reasonably simple and as far as I'm aware, it doesn't need
> >> more
> >>>> changes, we'd be glad to find a reviewer and having it merged:
> >>>> https://github.com/apache/calcite/pull/2808
> >>>>
> >>>> Viliam
> >>>>
> >>>> On Fri, 27 May 2022 at 21:49, Julian Hyde 
> >> wrote:
> >>>>
> >>>>> +1 mid-june release, and thank you to Ruben for sending the reminder.
> >>>>>
> >>>>> Three weeks ago we had a discussion about the fixVersion [1] field
> and
> >>>>> seemed to reach consensus. There were new responsibilities for the
> >> release
> >>>>> manager, as described here by Ruben:
> >>>>>
> >>>>>> Before starting the release process for version X, the
> >>>>>> release manager should take a look at Jira and find any
> >>>>>> tickets with fixVersion=X which are not resolved, and
> >>>>>> then act on a case by case basis, I guess starting a
> >>>>>> discussion on each ticket comments (so that
> >>>>>> everything is logged) with the reporter or any other
> >>>>>> contributor which may have done some work on it:
> >>>>>> - If the ticket is considered as a "Blocker", the release
> >>>>>>  process shall wait until it is done.
> >>>>>> - If the ticket is not a blocker:
> >>>>>> -- If it is reasonable to assume that it can be part of
> >>>>>>   the next (X+1) release (e.g. because work has
> >>>>>>   started already, just some elements are left to be
> >>>>>>   done etc.), the fixVersion can be changed into X+1.
> >>>>>> -- Otherwise its fixVersion shall be cleared ("unassigned").
> >>>>>
> >>>>> Andrei,
> >>>>>
> >>>>> Can you carry out the process described above? (It’s bad news for
> you,
> >>>>> because there are several issues that have been shunted forward
> >> several
> >>>>> times, but next release there should be fewer issues.) It basically
> >>>>> involves starting a conversation on every o

Re: [DISCUSS] Towards Calcite 1.31.0

2022-06-04 Thread Andrei Sereda
Hello,

I have created a JIRA filter
<https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20fixVersion%20%3D%201.31.0%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20%22In%20Review%22%2C%20%22In%20Implementation%22)%20ORDER%20BY%20priority%20DESC>
for 1.31 release. There are currently 25 unresolved issues (planned for
1.31).

If you are familiar with some of the JIRA tickets can you please review the
PRs and resolve the ticket ?

The plan is to have an RC in 1-2 weeks.

Regards,
Andrei.


On Sat, Jun 4, 2022 at 6:13 AM Vova Vysotskyi  wrote:

> Hello,
>
> Could we also include https://github.com/apache/calcite/pull/2305 into
> this release?
> I have rebased it onto the latest master and fixed all merge conflicts.
>
> Kind regards,
> Volodymyr Vysotskyi
>
> On 2022/05/30 17:57:28 Julian Hyde wrote:
> > Viliam, I marked the Jira case ‘fix in 1.31’ so that someone will at
> least review your PR.
> >
> > > On May 30, 2022, at 7:09 AM, Viliam Durina
>  wrote:
> > >
> > > Our PR is reasonably simple and as far as I'm aware, it doesn't need
> more
> > > changes, we'd be glad to find a reviewer and having it merged:
> > > https://github.com/apache/calcite/pull/2808
> > >
> > > Viliam
> > >
> > > On Fri, 27 May 2022 at 21:49, Julian Hyde 
> wrote:
> > >
> > >> +1 mid-june release, and thank you to Ruben for sending the reminder.
> > >>
> > >> Three weeks ago we had a discussion about the fixVersion [1] field and
> > >> seemed to reach consensus. There were new responsibilities for the
> release
> > >> manager, as described here by Ruben:
> > >>
> > >>> Before starting the release process for version X, the
> > >>> release manager should take a look at Jira and find any
> > >>> tickets with fixVersion=X which are not resolved, and
> > >>> then act on a case by case basis, I guess starting a
> > >>> discussion on each ticket comments (so that
> > >>> everything is logged) with the reporter or any other
> > >>> contributor which may have done some work on it:
> > >>> - If the ticket is considered as a "Blocker", the release
> > >>>   process shall wait until it is done.
> > >>> - If the ticket is not a blocker:
> > >>>  -- If it is reasonable to assume that it can be part of
> > >>>the next (X+1) release (e.g. because work has
> > >>>started already, just some elements are left to be
> > >>>done etc.), the fixVersion can be changed into X+1.
> > >>>  -- Otherwise its fixVersion shall be cleared ("unassigned").
> > >>
> > >> Andrei,
> > >>
> > >> Can you carry out the process described above? (It’s bad news for you,
> > >> because there are several issues that have been shunted forward
> several
> > >> times, but next release there should be fewer issues.) It basically
> > >> involves starting a conversation on every open/reopened JIRA case
> that is
> > >> marked fixVersion=1.31 about a week before the RC.
> > >>
> > >> If the process works we’ll add it to the HOWTO.
> > >>
> > >> Julian
> > >>
> > >> [1] https://lists.apache.org/thread/g8tjg0qxbot8b69rgv3poo618o3xvob1
> > >>
> > >>
> > >>> On May 26, 2022, at 12:58 AM, xiong duan 
> wrote:
> > >>>
> > >>> +1 for mid-June for the first RC.
> > >>>
> > >>> Benchao Li  于2022年5月26日周四 10:31写道:
> > >>>
> > >>>> +1 for mid-June for the first RC.
> > >>>> Thanks Ruben for driving this, and Andrei for being the RM.
> > >>>>
> > >>>> For me, I have two PRs[1][2] which I think it's good to have them in
> > >> 1.31.0
> > >>>> And for other issues which I've not opened pr yet, I think it's
> > >> reasonable
> > >>>> to postpone them to next version.
> > >>>>
> > >>>> [1] https://github.com/apache/calcite/pull/2791
> > >>>> [2] https://github.com/apache/calcite/pull/2813
> > >>>>
> > >>>> Andrei Sereda  于2022年5月26日周四 09:16写道:
> > >>>>
> > >>>>>> Andrei, are you still available for the task?
> > >>>>>
> > >>>>> Yes. I'm happy to be the Release Manager for 1.31
> > >>>>>

Re: [DISCUSS] Towards Calcite 1.31.0

2022-05-25 Thread Andrei Sereda
> Andrei, are you still available for the task?

Yes. I'm happy to be the Release Manager for 1.31

On Wed, May 25, 2022 at 9:15 PM Chunwei Lei  wrote:

> Thank you for taking care of this, Ruben.
>
> +1 for mid-June for the first RC.
>
>
> Best,
> Chunwei
>
>
> On Wed, May 25, 2022 at 4:26 PM Ruben Q L  wrote:
>
> > Hello,
> >
> > It has been more than two months since our last release [1], and I think
> we
> > should make an effort to continue keeping the rhythm of one release every
> > two months approximately.
> >
> > If I am not mistaken, the next release manager would be Andrei Sereda
> [2].
> > Andrei, are you still available for the task?
> >
> > As usual, according to our Jira dashboard [3] and Github [4], there are
> > many pending issues that could / should be part of the release. I'd
> propose
> > to make a collective effort to try to clean up our 1.31 backlog: complete
> > and merge the PRs which are in a reasonably good state, and push back to
> > 1.32 (or unassigned version) the Jira tickets that are not advanced
> enough
> > to be part of this release. Shall we give ourselves around two weeks for
> > this and aim at mid-June for the first RC? WDYT?
> >
> > Best regards,
> > Ruben
> >
> > [1] https://calcite.apache.org/news/2022/03/19/release-1.30.0/
> > [2] https://lists.apache.org/thread/ykbhhxmljw6wg50rxs6ypp35173hlkdv
> > [3]
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > [4] https://github.com/apache/calcite/pulls
> >
>


Re: [DISCUSS] Towards Calcite 1.30.0

2022-03-03 Thread Andrei Sereda
Hello,

Sorry for the delayed response. I was away for a couple of weeks.

I see that 1.30.0 is being released by Liya.

Can we swap Release Managers for 1.30 and 1.31 ? I'm happy to release
Calcite 1.31.

Thanks,
Andrei.



On Tue, Mar 1, 2022 at 9:40 PM Fan Liya  wrote:

> Got it. Thanks for the confirmation.
>
> Best,
> Liya Fan
>
> Stamatis Zampetakis  于2022年3月2日周三 05:30写道:
>
> > Since nobody objects, let's aim for Friday or whichever other day is
> > convenient for you.
> >
> > Best,
> > Stamatis
> >
> > On Sun, Feb 27, 2022 at 2:22 PM Fan Liya  wrote:
> >
> > > Thanks for your confirmation, Stamatis.
> > > How about next Friday (March 4th) to cut the first release candidate?
> > > Is that enough to get the PRs inside?
> > >
> > > Best,
> > > Liya Fan
> > >
> > >
> > > Stamatis Zampetakis  于2022年2月27日周日 05:57写道:
> > >
> > > > Many thanks Liya. Let's proceed like this then!
> > > >
> > > > Let us know when it would be the best time for you to cut the first
> > > release
> > > > candidate so that we plan appropriately and get some PRs inside.
> > > >
> > > > Best,
> > > > Stamatis
> > > >
> > > > On Fri, Feb 25, 2022 at 7:03 AM Fan Liya 
> wrote:
> > > >
> > > > > Sure. If Andrei is not available, I think I am OK.
> > > > >
> > > > > Best,
> > > > > Liya Fan
> > > > >
> > > > >
> > > > > Stamatis Zampetakis  于2022年2月24日周四 19:10写道:
> > > > >
> > > > > > Thanks for driving this Ruben!
> > > > > >
> > > > > > Another alternative if Andrei is unavailable at the moment would
> be
> > > to
> > > > > see
> > > > > > if they can switch places with Liya. Would this be possible Liya?
> > > > > >
> > > > > > Best,
> > > > > > Stamatis
> > > > > >
> > > > > > On Thu, Feb 24, 2022 at 10:41 AM Ruben Q L 
> > > wrote:
> > > > > >
> > > > > > > Friendly reminder.
> > > > > > >
> > > > > > > The next release managers would be:
> > > > > > > - Andrei Sereda for 1.30.0
> > > > > > > - Liya Fan for 1.31.0
> > > > > > >
> > > > > > > Andrei, are you available to be RM for 1.30? When would it be a
> > > good
> > > > > date
> > > > > > > for a RC?
> > > > > > >
> > > > > > > Ruben.
> > > > > > >
> > > > > > > PS: Do we have any other volunteers for the subsequent
> releases?
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Feb 16, 2022 at 12:59 AM xiong duan <
> nobigo...@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > +1 to release 1.30.  Feb 28th sounds good to me.
> > > > > > > >
> > > > > > > > Julian Hyde  于2022年2月16日周三 08:27写道:
> > > > > > > >
> > > > > > > > > +1 to release 1.30 soon, to keep up the tempo. Feb 28th
> > sounds
> > > > good
> > > > > > to
> > > > > > > > > me. Thanks for pushing on this, Ruben.
> > > > > > > > >
> > > > > > > > > Andrei, Are you available to be RM for 1.30? When is a good
> > > date
> > > > > for
> > > > > > > you?
> > > > > > > > >
> > > > > > > > > Julian
> > > > > > > > >
> > > > > > > > > On Mon, Feb 14, 2022 at 9:16 AM Ruben Q L <
> rube...@gmail.com
> > >
> > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > It has been almost two months since our last release [1],
> > > and I
> > > > > > think
> > > > > > > > we
> > > > > > > > > > should make an effort to continue keeping the rhythm of
> one
> > > > > release
> > > > > > > > every
> > > > > &g

Re: Mailing list's policy on job postings?

2022-01-04 Thread Andrei Sereda
Hello,

This was discussed here:

https://lists.apache.org/thread/31o50vg2k8oolqj19m7rj6cfto56owq5


Thanks,
Andrei

On Tue, Jan 4, 2022 at 6:17 PM Ian Bertolacci
 wrote:
>
> Howdy,
> What is this mailing list’s policy regarding job postings?
>
> Thanks!
> -Ian J. Bertolacci
>


Re: [DISCUSS] Upgrading Elasticsearch in Calcite from 7.0.1 to 7.15

2021-11-22 Thread Andrei Sereda
+1

Also take a look at vendor's official support schedule:

https://www.elastic.co/support/eol

I think it is safe to upgrade  ES rest client to currently supported
version.




On Mon, Nov 22, 2021, 19:00 Julian Hyde  wrote:

> +1
>
> Sounds like a good idea.
>
> > On Nov 22, 2021, at 6:40 AM, Zhe Hu  wrote:
> >
> > Hi, community.
> >
> >
> > Recently, when I tried to fix bugs in Elasticsearch Adapter, I’ve found
> that some new features in released Elasticsearch cannot be applied in
> Calcite, since the Elasticsearch version in Calcite is 7.0.1.
> >
> >
> > For instance, as CALCITE-4868 mentioned, I want to sort aggregation
> results by multi_terms(supported after ES 7.1.11) as it’s more suitable
> under such circumstances than terms aggregation, however the DSL is not
> supported in Calcite currently.
> >
> >
> > Moreover, I've browsed Elasticsearch's release notes roughly, and there
> are many new SQL features were added from 7.0.1 to 7.15.2, and lots of bugs
> were fixed meanwhile(if needed, I will spend some time to collect such info
> that benefits Calcite users).
> >
> >
> > Since we use RestClient in Elasticsearch Adapter, there are still some
> cons about upgrading ES version, like new DSL couldn’t be used in old
> version Elasticsearch cluster, current use case might need to be adjusted.
> >
> >
> > Nevertheless, I’m still wondering if we can upgrade the Elasticsearch
> version to 7.15, which could enrich ES Adapter's ablility as much as
> possible.
> >
> >
> > Best regards,
> > Zhe Hu
> >
> >
> >
>


Job postings on the dev list ?

2021-10-29 Thread Andrei Sereda
Hello,

I wanted to ask what members of this list think about receiving / posting
job opportunities (related to query optimisation / database engine) to
calcite-dev ?

Is it an appropriate usage of the dev@ list ? Should one use a different
channel ?

Thanks,
Andrei.


Re: (CALCITE-4292) Wrong results in ElasticSearch when query contains NOT EQUAL

2021-10-05 Thread Andrei Sereda
I also agree that we should preserve SQL semantics, regardless of the
adapter. For more details see a good article about Three Valued Logic
.


On Tue, Oct 5, 2021 at 11:32 AM Julian Hyde  wrote:

> I support Stamatis’ position. Our SQL adapter must implement SQL
> semantics. That is what users of a SQL interface want and expect.
>
> If Elasticsearch’s data model has nuances that cannot be captured in SQL,
> feel free to add extra operators. If name is a multi-valued attribute, then
> some ideas are IS_EMPTY(name), VALUE_COUNT(name), VALUE_SET(name).
>
> I’ve added these comments to
> https://issues.apache.org/jira/browse/CALCITE-4292.
>
> > On Oct 5, 2021, at 2:57 AM, Stamatis Zampetakis 
> wrote:
> >
> > Hi all,
> >
> > The question is basically how the following SQL statement should behave
> for
> > rows where the name is NULL in the ElasticSearch adapter.
> >
> > SELECT * from zips WHERE name <> "NMAX"
> >
> > I did add my comments in the JIRA case but it would be good if somebody
> > also expresses an opinion so that we resolve/close the issue.
> >
> > Best,
> > Stamatis
> >
> >> On Tue, Sep 28, 2021 at 2:52 PM Shlok Srivastava
> >>  wrote:
> >>
> >> Hi Community,
> >>
> >> Issue id -CALCITE-4292
> >> Issue name -Wrong results in ElasticSearch when query contains NOT EQUAL
> >>
> >> We made a change to modify not equals criteria in elasticsearch adapters
> >> as it was not in sync with Elasticsearch behavior.
> >>
> >> In-case of Not_Equals condition, the default behaviour of ElasticSearch
> as
> >> well as JSON path is to select records in which the mentioned field is
> >> missing, but as calcite prefers SQL semantics it adds EXISTS condition
> as
> >> well.
> >> Adding additional EXISTS condition in NOT_EQUALS criteria deviates from
> >> ElasticSearch behaviour. As the adapter is for ElasticSearch it should
> >> support ES behaviour. If someone requires exists along with NO_EQUALS
> >> condition it can be explicitly added in where condition but it can't be
> >> removed unless the code is fixed.
> >>
> >> So, this defect should be fixed to support default ElasticSearch
> behavior.
> >>
> >> For this change we have been informed that we require community
> feedback,
> >> so please share your thoughts/approval for same.
> >>
> >> Thanks,
> >> Shlok
> >>
> >> 
> >>
> >>
> >>
> >>
> >>
> >>
> >> NOTE: This message may contain information that is confidential,
> >> proprietary, privileged or otherwise protected by law. The message is
> >> intended solely for the named addressee. If received in error, please
> >> destroy and notify the sender. Any use of this email is prohibited when
> >> received in error. Impetus does not represent, warrant and/or guarantee,
> >> that the integrity of this communication has been maintained nor that
> the
> >> communication is free of errors, virus, interception or interference.
> >>
>


Re: [CALCITE-4232]-Elasticsearch IN Query is not supported

2021-09-22 Thread Andrei Sereda
Hi Arpit,

I'm also happy to take a look at your PR since I'm more or less familiar
with that part of the codebase.

Thanks,
Andrei



On Wed, Sep 22, 2021, 06:17 Stamatis Zampetakis  wrote:

> Hi Arpit,
>
> Given that it has been a long time since the last review there are quite a
> few things that changed in Calcite.
> I would suggest rebasing the PR based on the current master and I will try
> to have another look.
>
> Best,
> Stamatis
>
>
> On Mon, Sep 20, 2021 at 3:30 PM Arpit Motwani
>  wrote:
>
> > Hi Community,
> >
> > Please find below details of issue which we are facing in a pull request
> > raised by us for changes in ElasticsearchAdapters
> >
> > Issue Id- CALCITE-4232<
> https://issues.apache.org/jira/browse/CALCITE-4232>
> >
> > Above change has been accepted but is not merged upstream, is something
> > pending from our side ?
> >
> > Also, we see below error in PR of this change-
> >
> > This branch cannot be rebased due to conflicts
> >
> > Do we need to do something for the rebasing conflict? If yes kindly tell
> > us the approach for resolving this issue.
> >
> > Thanks & Regards
> >  Arpit Motwani
> >
> >
> > 
> >
> >
> >
> >
> >
> >
> > NOTE: This message may contain information that is confidential,
> > proprietary, privileged or otherwise protected by law. The message is
> > intended solely for the named addressee. If received in error, please
> > destroy and notify the sender. Any use of this email is prohibited when
> > received in error. Impetus does not represent, warrant and/or guarantee,
> > that the integrity of this communication has been maintained nor that the
> > communication is free of errors, virus, interception or interference.
> >
>


Re: [DISCUSS] Release Managers

2021-06-04 Thread Andrei Sereda
I volunteered for 1.30 but happy to release a different version.

On Fri, Jun 4, 2021 at 6:53 PM Haisheng Yuan  wrote:

> Thanks, Rui.
>
> Now we have release managers:
> Rui Wang for 1.29.0
> Liya Fan for 1.30.0
>
> Thanks,
> Haisheng Yuan
>
> On 2021/06/04 22:05:34, Rui Wang  wrote:
> > In another related thread I volunteered for releasing 1.29.0. I think I
> can
> > still do it.
> >
> >
> > -Rui
> >
> > On Thu, Jun 3, 2021 at 7:09 PM Fan Liya  wrote:
> >
> > > Hi Haisheng,
> > >
> > > I am interested in volunteering.
> > >
> > > Best,
> > > Liya Fan
> > >
> > > On Fri, Jun 4, 2021 at 6:50 AM Julian Hyde 
> wrote:
> > >
> > > > Yes, I am release manager for 1.28. I’ll aim to release first week of
> > > > August.
> > > >
> > > > Somewhat related to the call for release managers: we need active
> > > > committers. (Stamatis, can you run your stats on PRs and active
> > > > committers?) On May 21, I noted that PR backlog is building up, and
> > > > appealed for 5 committers to look at 5 PRs each. But since then only
> 2
> > > PRs
> > > > have been committed (thanks Ruben & Stamatis). We need to do better.
> > > >
> > > > Julian
> > > >
> > > >
> > > > > On Jun 3, 2021, at 3:33 PM, Haisheng Yuan 
> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > In the next half year, I hope we can get back to the pace of
> release
> > > for
> > > > every 2 months. We need more release managers for the next few
> releases,
> > > is
> > > > there any one interested in volunteering to be release manager?
> > > > > Currently Julian is the release manager for 1.28.0, we need 3 more
> for
> > > > 1.29.0 ~ 1.31.0.
> > > > >
> > > > > Thanks,
> > > > > Haisheng Yuan
> > > >
> > > >
> > >
> >
>


Re: [DISCUSS] Release Managers

2021-02-04 Thread Andrei Sereda
I'm happy to help with 1.30

On Thu, Feb 4, 2021 at 1:27 PM Julian Hyde  wrote:

> Yes, I'll be release manager for 1.28.
>
> I think I promised to be a release manager a while ago. I forget which
> release. Sorry about that.
>
> On Thu, Feb 4, 2021 at 1:09 AM Stamatis Zampetakis 
> wrote:
> >
> > That would be great Rui, thanks for volunteering. So far we have:
> >
> > 1.27 Stamatis
> > 1.28 Julian ?
> > 1.29 Rui
> >
> > It would be nice to also plan for 1.30 & 1.31 just to be a bit ahead of
> > time. Are there other people willing to help?
> >
> > Best,
> > Stamatis
> >
> >
> > On Wed, Feb 3, 2021 at 12:32 AM Rui Wang  wrote:
> >
> > > I can also help on releasing (haven't done one for Calcite).
> > >
> > >
> > > -Rui
> > >
> > > On Tue, Aug 18, 2020 at 2:32 PM Julian Hyde  wrote:
> > >
> > > > I haven't been RM for a while. I'll do 1.27, then Stamatis can do
> 1.28.
> > > >
> > > > On Sun, Aug 16, 2020 at 1:57 AM Stamatis Zampetakis <
> zabe...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Depending on the timing I can possibly get 1.27.0 or 1.28.0.
> > > > >
> > > > > Best,
> > > > > Stamatis
> > > > >
> > > > > On Fri, Aug 14, 2020 at 2:58 AM Haisheng Yuan 
> > > wrote:
> > > > >
> > > > > > Thanks for volunteering, Ruben! I think you can be the release
> > > manager
> > > > for
> > > > > > 1.26.0.
> > > > > >
> > > > > > We still need 2 more volunteers for the next 2 versions.
> > > > > >
> > > > > > Thanks,
> > > > > > Haisheng
> > > > > >
> > > > > > On 2020/07/25 15:24:43, Ruben Q L  wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I can volunteer for one of them, for example 1.26.0
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Ruben
> > > > > > >
> > > > > > >
> > > > > > > Le sam. 25 juil. 2020 à 15:23, Haisheng Yuan 
> a
> > > > écrit
> > > > > > :
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Would anyone be interested in being release manager for
> v1.26.0,
> > > > > > v1.27.0
> > > > > > > > or v1.28.0?
> > > > > > > > We need 3 volunteers (must be PMC or committer) for these 3
> > > > versions.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Haisheng Yuan
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
>


Re: How to test new datasource without "in memory/mock" implementation

2020-10-18 Thread Andrei Sereda
I agree with Julian. Not everybody has the option to run docker locally.

Perhaps execute tests against embedded (or fake) instance as well as a real
one (docker or externally managed) ? Like it is done in
MongoDatabasePolicy.java [1]

Currently tests for Elasticsearch, Geode and Mongo are all run against
embedded test instances but one should be able to execute them against a
real one as well.

https://github.com/apache/calcite/blob/master/mongodb/src/test/java/org/apache/calcite/adapter/mongodb/MongoDatabasePolicy.java#L70
[1]


On Sun, Oct 18, 2020 at 3:30 AM Tugdual Grall  wrote:

> Ok
>
> I will look more into it
>
> On Sun, Oct 18, 2020 at 8:54 AM Julian Hyde 
> wrote:
>
> > This would be inconvenient for me personally. My company does not allow
> me
> > to run Docker on my work  computer.
> >
> > Julian
> >
> > > On Oct 17, 2020, at 11:31 PM, Tugdual Grall  wrote:
> > >
> > > Hi
> > >
> > > I have created this PR to share with the community what could be done:
> > > * https://github.com/apache/calcite/pull/2223
> > >
> > > And associated issue
> https://issues.apache.org/jira/browse/CALCITE-4344
> > >
> > > I guess we will continue the discussion on the issue itself
> > >
> > > Tug
> > >
> > >> On Sat, Oct 17, 2020 at 11:05 PM Vladimir Sitnikov <
> > >> sitnikov.vladi...@gmail.com> wrote:
> > >>
> > >> Tugdual>Are we "allowed" to use containers in the tests, for example
> > >> using TestContainers
> > >>
> > >> I believe Testcontainers-based tests are more than welcome, however,
> > >> nobody implemented that yet.
> > >> It would be great if you could contribute that.
> > >>
> > >> Vladimir
> > >>
> > >>
> >
>


Re: [VOTE] Release apache-calcite-1.26.0 (release candidate 0)

2020-10-05 Thread Andrei Sereda
+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  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 于2020年10月5日 周一下午10:58写道:
>
> > Il giorno lun 5 ott 2020 alle ore 16:43 Ruben Q L  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 
> >
> > > 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.vladi...@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: [RESULT] [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-22 Thread Andrei Sereda
Thank you, Fancis.

I have marked 1.25 as released in JIRA

On Sat, Aug 22, 2020 at 7:28 PM Francis Chuang 
wrote:

> Hey Andrei,
>
> I added the 1.25.0 release to the reporting tool.
> I also added you to the administrator role in jira. Can you see if you
> can mark 1.25.0 as released?
>
> Francis
>
> On 23/08/2020 8:29 am, Andrei Sereda wrote:
> > There are two things to be done by PMCs (unfortunately I can't due to
> > restricted access):
> >
> > 1. Add release date 2020-08-22 for 1.25 to Apache Report Helper [1]
> > 2. Mark version 1.25 as released in JIRA [2]. Release date 2020-08-22
> >
> > If someone has access to those systems please help me finalize 1.25
> >
> > [1] https://reporter.apache.org/addrelease.html?calcite
> > [2] https://issues.apache.org/jira/projects/CALCITE/versions/12348564
> >
> > On Sat, Aug 22, 2020 at 3:49 PM Michael Mior  wrote:
> >
> >> Thanks Andrei!
> >>
> >> --
> >> Michael Mior
> >> mm...@apache.org
> >>
> >> Le sam. 22 août 2020 à 15:08, Andrei Sereda  a écrit
> :
> >>>
> >>> INFRA-20681 was resolved.
> >>>
> >>> I have published the artifacts to SVN dist area.
> >>>
> >>> Will update static site and send an announcement shortly.
> >>>
> >>> On Fri, Aug 21, 2020 at 5:37 PM Andrei Sereda 
> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> I'm still waiting for INFRA-20681 [1] to be resolved to publish 1.25.0
> >>>> artifacts to SVN. If some of you know different channels to speed up
> >> the
> >>>> resolution please let me know.
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/INFRA-20681
> >>>>
> >>>> On Sun, Aug 16, 2020 at 12:58 PM Andrei Sereda 
> >> wrote:
> >>>>
> >>>>> 1.25 branch has been merged.
> >>>>>
> >>>>> Master is unlocked now. I have also sent separate notification.
> >>>>>
> >>>>> On Sat, Aug 15, 2020 at 7:07 PM Julian Hyde 
> wrote:
> >>>>>
> >>>>>> You can "git push origin calcite-1.25.0-rc0:master" and then re-open
> >>>>>> master. I don't think there's any reason to wait. Since the release
> >>>>>> vote has passed, we know that 68b02dfd4 is going to end up on
> master.
> >>>>>> And we don't mind if people make intervening commits before you
> tweak
> >>>>>> the release notes or whatever.
> >>>>>>
> >>>>>> On Sat, Aug 15, 2020 at 3:12 PM Andrei Sereda 
> >> wrote:
> >>>>>>>
> >>>>>>>> is there any reason to keep master branch closed?
> >>>>>>> I didn't want to make master branch too out of sync with 1.25.0
> >>>>>> release.
> >>>>>>> Unfortunately I was not yet given permissions for SVN dist
> >> repository
> >>>>>> which
> >>>>>>> prevents me from finalizing the release.
> >>>>>>>
> >>>>>>> That being said, keeping master frozen for too long is not
> >> optimal. I
> >>>>>> will
> >>>>>>> merge existing release branch today and hopefully finalize 1.25
> >> next
> >>>>>> week
> >>>>>>> independently.
> >>>>>>>
> >>>>>>> Sorry for the inconvenience.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sat, Aug 15, 2020 at 2:47 PM Julian Hyde 
> >> wrote:
> >>>>>>>
> >>>>>>>> Andrei,
> >>>>>>>>
> >>>>>>>> Now the release is final, is there any reason to keep master
> >> branch
> >>>>>> closed?
> >>>>>>>>
> >>>>>>>> (Usually we push branch-x.x to master and re-open commits as
> >> soon as
> >>>>>>>> the release vote passes. Amendments to release notes, if
> >> necessary,
> >>>>>>>> can happen later.)
> >>>>>>>>
> >>>>>>>> Julian
> >>>>>>>>
> >>>>>>>> On Wed, Aug 12, 2020 at 11:13 AM Andrei Sereda  >>>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Thanks to everyone who has tested the release candidate and
> >> given
> >>>>>> their
> >>>>>>>>> comments and votes.
> >>>>>>>>>
> >>>>>>>>> The tally is as follows.
> >>>>>>>>>
> >>>>>>>>> 4 binding +1s:
> >>>>>>>>>   * Francis Chuang
> >>>>>>>>>   * Michael Mior
> >>>>>>>>>   * Haisheng Yuan
> >>>>>>>>>   * Julian Hyde
> >>>>>>>>>
> >>>>>>>>> 7 non-binding +1s:
> >>>>>>>>>   * Enrico Olivelli
> >>>>>>>>>   * Rui Wang
> >>>>>>>>>   * chunwei
> >>>>>>>>>   * Ruben Q L
> >>>>>>>>>   * Anton Haidai
> >>>>>>>>>   * xzh
> >>>>>>>>>   * Andrei Sereda
> >>>>>>>>>
> >>>>>>>>> No 0s or -1s.
> >>>>>>>>>
> >>>>>>>>> Therefore I am delighted to announce that the proposal to
> >> release
> >>>>>> Apache
> >>>>>>>>> Calcite 1.25.0 has passed.
> >>>>>>>>>
> >>>>>>>>> Thanks everyone. We’ll now roll the release out to the mirrors.
> >>>>>>>>>
> >>>>>>>>> I will also update release notes (in separate commit) to better
> >>>>>>>>> reflect 1.25.0 changes.
> >>>>>>>>>
> >>>>>>>>> Please refrain from modifying master until release is over.
> >>>>>> Separate
> >>>>>>>>> notification will be sent once commits are allowed.
> >>>>>>>>>
> >>>>>>>>> Andrei
> >>>>>>>>
> >>>>>>
> >>>>>
> >>
> >
>


Re: [RESULT] [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-22 Thread Andrei Sereda
There are two things to be done by PMCs (unfortunately I can't due to
restricted access):

1. Add release date 2020-08-22 for 1.25 to Apache Report Helper [1]
2. Mark version 1.25 as released in JIRA [2]. Release date 2020-08-22

If someone has access to those systems please help me finalize 1.25

[1] https://reporter.apache.org/addrelease.html?calcite
[2] https://issues.apache.org/jira/projects/CALCITE/versions/12348564

On Sat, Aug 22, 2020 at 3:49 PM Michael Mior  wrote:

> Thanks Andrei!
>
> --
> Michael Mior
> mm...@apache.org
>
> Le sam. 22 août 2020 à 15:08, Andrei Sereda  a écrit :
> >
> > INFRA-20681 was resolved.
> >
> > I have published the artifacts to SVN dist area.
> >
> > Will update static site and send an announcement shortly.
> >
> > On Fri, Aug 21, 2020 at 5:37 PM Andrei Sereda  wrote:
> >
> > > Hello,
> > >
> > > I'm still waiting for INFRA-20681 [1] to be resolved to publish 1.25.0
> > > artifacts to SVN. If some of you know different channels to speed up
> the
> > > resolution please let me know.
> > >
> > > [1] https://issues.apache.org/jira/browse/INFRA-20681
> > >
> > > On Sun, Aug 16, 2020 at 12:58 PM Andrei Sereda 
> wrote:
> > >
> > >> 1.25 branch has been merged.
> > >>
> > >> Master is unlocked now. I have also sent separate notification.
> > >>
> > >> On Sat, Aug 15, 2020 at 7:07 PM Julian Hyde  wrote:
> > >>
> > >>> You can "git push origin calcite-1.25.0-rc0:master" and then re-open
> > >>> master. I don't think there's any reason to wait. Since the release
> > >>> vote has passed, we know that 68b02dfd4 is going to end up on master.
> > >>> And we don't mind if people make intervening commits before you tweak
> > >>> the release notes or whatever.
> > >>>
> > >>> On Sat, Aug 15, 2020 at 3:12 PM Andrei Sereda 
> wrote:
> > >>> >
> > >>> > > is there any reason to keep master branch closed?
> > >>> > I didn't want to make master branch too out of sync with 1.25.0
> > >>> release.
> > >>> > Unfortunately I was not yet given permissions for SVN dist
> repository
> > >>> which
> > >>> > prevents me from finalizing the release.
> > >>> >
> > >>> > That being said, keeping master frozen for too long is not
> optimal. I
> > >>> will
> > >>> > merge existing release branch today and hopefully finalize 1.25
> next
> > >>> week
> > >>> > independently.
> > >>> >
> > >>> > Sorry for the inconvenience.
> > >>> >
> > >>> >
> > >>> >
> > >>> >
> > >>> >
> > >>> > On Sat, Aug 15, 2020 at 2:47 PM Julian Hyde 
> wrote:
> > >>> >
> > >>> > > Andrei,
> > >>> > >
> > >>> > > Now the release is final, is there any reason to keep master
> branch
> > >>> closed?
> > >>> > >
> > >>> > > (Usually we push branch-x.x to master and re-open commits as
> soon as
> > >>> > > the release vote passes. Amendments to release notes, if
> necessary,
> > >>> > > can happen later.)
> > >>> > >
> > >>> > > Julian
> > >>> > >
> > >>> > > On Wed, Aug 12, 2020 at 11:13 AM Andrei Sereda  >
> > >>> wrote:
> > >>> > > >
> > >>> > > > Thanks to everyone who has tested the release candidate and
> given
> > >>> their
> > >>> > > > comments and votes.
> > >>> > > >
> > >>> > > > The tally is as follows.
> > >>> > > >
> > >>> > > > 4 binding +1s:
> > >>> > > >  * Francis Chuang
> > >>> > > >  * Michael Mior
> > >>> > > >  * Haisheng Yuan
> > >>> > > >  * Julian Hyde
> > >>> > > >
> > >>> > > > 7 non-binding +1s:
> > >>> > > >  * Enrico Olivelli
> > >>> > > >  * Rui Wang
> > >>> > > >  * chunwei
> > >>> > > >  * Ruben Q L
> > >>> > > >  * Anton Haidai
> > >>> > > >  * xzh
> > >>> > > >  * Andrei Sereda
> > >>> > > >
> > >>> > > > No 0s or -1s.
> > >>> > > >
> > >>> > > > Therefore I am delighted to announce that the proposal to
> release
> > >>> Apache
> > >>> > > > Calcite 1.25.0 has passed.
> > >>> > > >
> > >>> > > > Thanks everyone. We’ll now roll the release out to the mirrors.
> > >>> > > >
> > >>> > > > I will also update release notes (in separate commit) to better
> > >>> > > > reflect 1.25.0 changes.
> > >>> > > >
> > >>> > > > Please refrain from modifying master until release is over.
> > >>> Separate
> > >>> > > > notification will be sent once commits are allowed.
> > >>> > > >
> > >>> > > > Andrei
> > >>> > >
> > >>>
> > >>
>


Re: [RESULT] [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-22 Thread Andrei Sereda
INFRA-20681 was resolved.

I have published the artifacts to SVN dist area.

Will update static site and send an announcement shortly.

On Fri, Aug 21, 2020 at 5:37 PM Andrei Sereda  wrote:

> Hello,
>
> I'm still waiting for INFRA-20681 [1] to be resolved to publish 1.25.0
> artifacts to SVN. If some of you know different channels to speed up the
> resolution please let me know.
>
> [1] https://issues.apache.org/jira/browse/INFRA-20681
>
> On Sun, Aug 16, 2020 at 12:58 PM Andrei Sereda  wrote:
>
>> 1.25 branch has been merged.
>>
>> Master is unlocked now. I have also sent separate notification.
>>
>> On Sat, Aug 15, 2020 at 7:07 PM Julian Hyde  wrote:
>>
>>> You can "git push origin calcite-1.25.0-rc0:master" and then re-open
>>> master. I don't think there's any reason to wait. Since the release
>>> vote has passed, we know that 68b02dfd4 is going to end up on master.
>>> And we don't mind if people make intervening commits before you tweak
>>> the release notes or whatever.
>>>
>>> On Sat, Aug 15, 2020 at 3:12 PM Andrei Sereda  wrote:
>>> >
>>> > > is there any reason to keep master branch closed?
>>> > I didn't want to make master branch too out of sync with 1.25.0
>>> release.
>>> > Unfortunately I was not yet given permissions for SVN dist repository
>>> which
>>> > prevents me from finalizing the release.
>>> >
>>> > That being said, keeping master frozen for too long is not optimal. I
>>> will
>>> > merge existing release branch today and hopefully finalize 1.25 next
>>> week
>>> > independently.
>>> >
>>> > Sorry for the inconvenience.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Sat, Aug 15, 2020 at 2:47 PM Julian Hyde  wrote:
>>> >
>>> > > Andrei,
>>> > >
>>> > > Now the release is final, is there any reason to keep master branch
>>> closed?
>>> > >
>>> > > (Usually we push branch-x.x to master and re-open commits as soon as
>>> > > the release vote passes. Amendments to release notes, if necessary,
>>> > > can happen later.)
>>> > >
>>> > > Julian
>>> > >
>>> > > On Wed, Aug 12, 2020 at 11:13 AM Andrei Sereda 
>>> wrote:
>>> > > >
>>> > > > Thanks to everyone who has tested the release candidate and given
>>> their
>>> > > > comments and votes.
>>> > > >
>>> > > > The tally is as follows.
>>> > > >
>>> > > > 4 binding +1s:
>>> > > >  * Francis Chuang
>>> > > >  * Michael Mior
>>> > > >  * Haisheng Yuan
>>> > > >  * Julian Hyde
>>> > > >
>>> > > > 7 non-binding +1s:
>>> > > >  * Enrico Olivelli
>>> > > >  * Rui Wang
>>> > > >  * chunwei
>>> > > >  * Ruben Q L
>>> > > >  * Anton Haidai
>>> > > >  * xzh
>>> > > >  * Andrei Sereda
>>> > > >
>>> > > > No 0s or -1s.
>>> > > >
>>> > > > Therefore I am delighted to announce that the proposal to release
>>> Apache
>>> > > > Calcite 1.25.0 has passed.
>>> > > >
>>> > > > Thanks everyone. We’ll now roll the release out to the mirrors.
>>> > > >
>>> > > > I will also update release notes (in separate commit) to better
>>> > > > reflect 1.25.0 changes.
>>> > > >
>>> > > > Please refrain from modifying master until release is over.
>>> Separate
>>> > > > notification will be sent once commits are allowed.
>>> > > >
>>> > > > Andrei
>>> > >
>>>
>>


Re: [RESULT] [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-21 Thread Andrei Sereda
Hello,

I'm still waiting for INFRA-20681 [1] to be resolved to publish 1.25.0
artifacts to SVN. If some of you know different channels to speed up the
resolution please let me know.

[1] https://issues.apache.org/jira/browse/INFRA-20681

On Sun, Aug 16, 2020 at 12:58 PM Andrei Sereda  wrote:

> 1.25 branch has been merged.
>
> Master is unlocked now. I have also sent separate notification.
>
> On Sat, Aug 15, 2020 at 7:07 PM Julian Hyde  wrote:
>
>> You can "git push origin calcite-1.25.0-rc0:master" and then re-open
>> master. I don't think there's any reason to wait. Since the release
>> vote has passed, we know that 68b02dfd4 is going to end up on master.
>> And we don't mind if people make intervening commits before you tweak
>> the release notes or whatever.
>>
>> On Sat, Aug 15, 2020 at 3:12 PM Andrei Sereda  wrote:
>> >
>> > > is there any reason to keep master branch closed?
>> > I didn't want to make master branch too out of sync with 1.25.0 release.
>> > Unfortunately I was not yet given permissions for SVN dist repository
>> which
>> > prevents me from finalizing the release.
>> >
>> > That being said, keeping master frozen for too long is not optimal. I
>> will
>> > merge existing release branch today and hopefully finalize 1.25 next
>> week
>> > independently.
>> >
>> > Sorry for the inconvenience.
>> >
>> >
>> >
>> >
>> >
>> > On Sat, Aug 15, 2020 at 2:47 PM Julian Hyde  wrote:
>> >
>> > > Andrei,
>> > >
>> > > Now the release is final, is there any reason to keep master branch
>> closed?
>> > >
>> > > (Usually we push branch-x.x to master and re-open commits as soon as
>> > > the release vote passes. Amendments to release notes, if necessary,
>> > > can happen later.)
>> > >
>> > > Julian
>> > >
>> > > On Wed, Aug 12, 2020 at 11:13 AM Andrei Sereda 
>> wrote:
>> > > >
>> > > > Thanks to everyone who has tested the release candidate and given
>> their
>> > > > comments and votes.
>> > > >
>> > > > The tally is as follows.
>> > > >
>> > > > 4 binding +1s:
>> > > >  * Francis Chuang
>> > > >  * Michael Mior
>> > > >  * Haisheng Yuan
>> > > >  * Julian Hyde
>> > > >
>> > > > 7 non-binding +1s:
>> > > >  * Enrico Olivelli
>> > > >  * Rui Wang
>> > > >  * chunwei
>> > > >  * Ruben Q L
>> > > >  * Anton Haidai
>> > > >  * xzh
>> > > >  * Andrei Sereda
>> > > >
>> > > > No 0s or -1s.
>> > > >
>> > > > Therefore I am delighted to announce that the proposal to release
>> Apache
>> > > > Calcite 1.25.0 has passed.
>> > > >
>> > > > Thanks everyone. We’ll now roll the release out to the mirrors.
>> > > >
>> > > > I will also update release notes (in separate commit) to better
>> > > > reflect 1.25.0 changes.
>> > > >
>> > > > Please refrain from modifying master until release is over. Separate
>> > > > notification will be sent once commits are allowed.
>> > > >
>> > > > Andrei
>> > >
>>
>


Re: master locked during 1.25.0 release

2020-08-16 Thread Andrei Sereda
Hello,

Following the vote on 1.25 release and Julian's suggestion to open up
master sooner, I have merged 1.25 release with master.

master branch is unlocked now. You can resume normal development flow.

Please note that there is no official release yet (pending INFRA-20681).
Actual 1.25 will happen independently from commit 68b02dfd4.

Thank you,
Andrei.




On Tue, Aug 11, 2020 at 5:57 AM Julian Hyde  wrote:

> Danny,
>
> Master branch is still locked.
>
> I have backed out your commit
> https://github.com/apache/calcite/commit/aadb605decd6bb6a853e23fac4b0f479b2397e06
> <
> https://github.com/apache/calcite/commit/aadb605decd6bb6a853e23fac4b0f479b2397e06
> >.
>
> Julian
>
>
> > On Aug 7, 2020, at 7:03 PM, Andrei Sereda  wrote:
> >
> > Hello,
> >
> > Please avoid committing anything to master while 1.25.0 release is in
> > progress.
> >
> > It will be unlocked after the voting / successful release.
> >
> > Many thanks,
> > Andrei.
>
>


Re: [RESULT] [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-15 Thread Andrei Sereda
> is there any reason to keep master branch closed?
I didn't want to make master branch too out of sync with 1.25.0 release.
Unfortunately I was not yet given permissions for SVN dist repository which
prevents me from finalizing the release.

That being said, keeping master frozen for too long is not optimal. I will
merge existing release branch today and hopefully finalize 1.25 next week
independently.

Sorry for the inconvenience.





On Sat, Aug 15, 2020 at 2:47 PM Julian Hyde  wrote:

> Andrei,
>
> Now the release is final, is there any reason to keep master branch closed?
>
> (Usually we push branch-x.x to master and re-open commits as soon as
> the release vote passes. Amendments to release notes, if necessary,
> can happen later.)
>
> Julian
>
> On Wed, Aug 12, 2020 at 11:13 AM Andrei Sereda  wrote:
> >
> > Thanks to everyone who has tested the release candidate and given their
> > comments and votes.
> >
> > The tally is as follows.
> >
> > 4 binding +1s:
> >  * Francis Chuang
> >  * Michael Mior
> >  * Haisheng Yuan
> >  * Julian Hyde
> >
> > 7 non-binding +1s:
> >  * Enrico Olivelli
> >  * Rui Wang
> >  * chunwei
> >  * Ruben Q L
> >  * Anton Haidai
> >  * xzh
> >  * Andrei Sereda
> >
> > No 0s or -1s.
> >
> > Therefore I am delighted to announce that the proposal to release Apache
> > Calcite 1.25.0 has passed.
> >
> > Thanks everyone. We’ll now roll the release out to the mirrors.
> >
> > I will also update release notes (in separate commit) to better
> > reflect 1.25.0 changes.
> >
> > Please refrain from modifying master until release is over. Separate
> > notification will be sent once commits are allowed.
> >
> > Andrei
>


Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-13 Thread Andrei Sereda
Hi Haisheng,

Thanks for your reply.

There is a parallel discussion [1] about letting committers have write
access to SVN dist repository. Seems like most people are on the same page
(ie +1).
If approved, I should be able to finalize the release soon myself.

Andrei.


[1]
https://lists.apache.org/thread.html/raf959fc1e4e5d143ce220589de9cb798c51d39b9e1faf4b682bda9ba%40%3Cdev.calcite.apache.org%3E


On Thu, Aug 13, 2020 at 6:02 PM Haisheng Yuan  wrote:

> Hi Andrei,
>
> Let's unblock the release as soon as possible.
> I can help publish the artifact.
>
> Can you cat build/stagingRepositories/nexus.txt and send me the content in
> your local repo?
>
> Thanks,
> Haisheng
>
> On 2020/08/13 14:47:05, Andrei Sereda  wrote:
> > It can also be configured per project.
> >
> > > Do you know if SVN access can be configured per project ?
> > > Yes it can, if the PMC agrees to it, the dist area can be opened up to
> > all project committers - a few PMCs have done this.
> >
> > On Thu, Aug 13, 2020 at 10:43 AM Andrei Sereda  wrote:
> >
> > > Inquired with INFRA-20681
> > > <https://issues.apache.org/jira/browse/INFRA-20681> seems like only
> PMCs
> > > can commit to dist SVN:
> > >
> > > > Are committers (which are not PMCs) allowed to commit to SVN dist
> repo ?
> > > > ..., nope, by default its PMC members only
> > >
> > >
> > >
> > > On Thu, Aug 13, 2020 at 9:27 AM Andrei Sereda 
> wrote:
> > >
> > >> Can someone from PMC pls publish the release ?  Or maybe contact INFRA
> > >> about svn permissions for committers vs PMCs ?
> > >>
> > >> I would like to avoid blocking calcite development for too long.
> > >>
> > >>
> > >> On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei 
> > >> wrote:
> > >>
> > >>> > Once this release is done, we should consider whether we should
> give
> > >>> committers write access to SVN to avoid these issues in the future.
> I am
> > >>> not sure if this is possible or if this is just the way ASF's infra
> is
> > >>> set up, but it's worth a look.
> > >>>
> > >>> I cannot agree more. Thank you for pointing out, Francis.
> > >>> (We can add some notes about it at least~~)
> > >>>
> > >>>
> > >>>
> > >>> Best,
> > >>> Chunwei
> > >>>
> > >>>
> > >>> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang <
> > >>> francischu...@apache.org>
> > >>> wrote:
> > >>>
> > >>> > Can someone please push the release artifacts for Andrei? I believe
> > >>> this
> > >>> > is the same issue we had with the last release, where the RM is
> not a
> > >>> > PMC member and doesn't have write access to SVN [1].
> > >>> >
> > >>> > Once this release is done, we should consider whether we should
> give
> > >>> > committers write access to SVN to avoid these issues in the
> future. I
> > >>> am
> > >>> > not sure if this is possible or if this is just the way ASF's
> infra is
> > >>> > set up, but it's worth a look.
> > >>> >
> > >>> > Francis
> > >>> >
> > >>> > [1]
> > >>> >
> > >>> >
> > >>>
> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
> > >>> >
> > >>> > On 13/08/2020 8:51 am, Andrei Sereda wrote:
> > >>> > > Thanks, Stamatis. All seems to be working now.
> > >>> > >
> > >>> > > On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis <
> > >>> zabe...@gmail.com>
> > >>> > > wrote:
> > >>> > >
> > >>> > >> Hi Andrei,
> > >>> > >>
> > >>> > >> I uploaded your key to the file. Please check.
> > >>> > >>
> > >>> > >> Normally you don't need to be in the PMC to have access to the
> svn
> > >>> repo.
> > >>> > >> I don't know what went wrong and you were not able to push it
> > >>> through.
> > >>> > >>
> > >>> > >> Best,
> > >>> > >> Stamatis

[DISCUSS] Open SVN dist access to committers

2020-08-13 Thread Andrei Sereda
Hello,

For the last two releases ([1] and [2]) committers were not able to
finalize the release due to SVN restrictions. One of the PMC members had to
step in order to distribute the artifacts.

By default, only PMCs are allowed to make changes to dist
 SVN repository.

This can be changed
.
According to INFA:

> A link on this Jira to an email discussion where it is approved will be
fine

PMCs please vote on this proposal.

Thanks,
Andrei.

[1]
https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E
[2]
https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E


Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-13 Thread Andrei Sereda
It can also be configured per project.

> Do you know if SVN access can be configured per project ?
> Yes it can, if the PMC agrees to it, the dist area can be opened up to
all project committers - a few PMCs have done this.

On Thu, Aug 13, 2020 at 10:43 AM Andrei Sereda  wrote:

> Inquired with INFRA-20681
> <https://issues.apache.org/jira/browse/INFRA-20681> seems like only PMCs
> can commit to dist SVN:
>
> > Are committers (which are not PMCs) allowed to commit to SVN dist repo ?
> > ..., nope, by default its PMC members only
>
>
>
> On Thu, Aug 13, 2020 at 9:27 AM Andrei Sereda  wrote:
>
>> Can someone from PMC pls publish the release ?  Or maybe contact INFRA
>> about svn permissions for committers vs PMCs ?
>>
>> I would like to avoid blocking calcite development for too long.
>>
>>
>> On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei 
>> wrote:
>>
>>> > Once this release is done, we should consider whether we should give
>>> committers write access to SVN to avoid these issues in the future. I am
>>> not sure if this is possible or if this is just the way ASF's infra is
>>> set up, but it's worth a look.
>>>
>>> I cannot agree more. Thank you for pointing out, Francis.
>>> (We can add some notes about it at least~~)
>>>
>>>
>>>
>>> Best,
>>> Chunwei
>>>
>>>
>>> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang <
>>> francischu...@apache.org>
>>> wrote:
>>>
>>> > Can someone please push the release artifacts for Andrei? I believe
>>> this
>>> > is the same issue we had with the last release, where the RM is not a
>>> > PMC member and doesn't have write access to SVN [1].
>>> >
>>> > Once this release is done, we should consider whether we should give
>>> > committers write access to SVN to avoid these issues in the future. I
>>> am
>>> > not sure if this is possible or if this is just the way ASF's infra is
>>> > set up, but it's worth a look.
>>> >
>>> > Francis
>>> >
>>> > [1]
>>> >
>>> >
>>> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
>>> >
>>> > On 13/08/2020 8:51 am, Andrei Sereda wrote:
>>> > > Thanks, Stamatis. All seems to be working now.
>>> > >
>>> > > On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis <
>>> zabe...@gmail.com>
>>> > > wrote:
>>> > >
>>> > >> Hi Andrei,
>>> > >>
>>> > >> I uploaded your key to the file. Please check.
>>> > >>
>>> > >> Normally you don't need to be in the PMC to have access to the svn
>>> repo.
>>> > >> I don't know what went wrong and you were not able to push it
>>> through.
>>> > >>
>>> > >> Best,
>>> > >> Stamatis
>>> > >>
>>> > >> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda 
>>> wrote:
>>> > >>
>>> > >>> Hello,
>>> > >>>
>>> > >>> Can somebody from PMC pls upload my public GPG key to KEYS
>>> > >>> <https://dist.apache.org/repos/dist/release/calcite/KEYS> ? I
>>> don't
>>> > have
>>> > >>> permissions for that svn repo.
>>> > >>>
>>> > >>> I've sent an email to priv...@calcite.apache.org.
>>> > >>>
>>> > >>> Thanks,
>>> > >>> Andrei.
>>> > >>>
>>> > >>> On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda 
>>> > wrote:
>>> > >>>
>>> > >>>> Hi All,
>>> > >>>>
>>> > >>>> I plan to close the vote tomorrow (Aug 12th). If you still want to
>>> > >>>> validate RC0 please do so before Wednesday.
>>> > >>>>
>>> > >>>> Regards,
>>> > >>>> Andrei.
>>> > >>>>
>>> > >>>> On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda 
>>> > >> wrote:
>>> > >>>>
>>> > >>>>> Thanks, Julian, for the hint. I'll update the KEYS file.
>>> > >>>>>
>>> > >>>>> On

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-13 Thread Andrei Sereda
Inquired with INFRA-20681
<https://issues.apache.org/jira/browse/INFRA-20681> seems like only PMCs
can commit to dist SVN:

> Are committers (which are not PMCs) allowed to commit to SVN dist repo ?
> ..., nope, by default its PMC members only



On Thu, Aug 13, 2020 at 9:27 AM Andrei Sereda  wrote:

> Can someone from PMC pls publish the release ?  Or maybe contact INFRA
> about svn permissions for committers vs PMCs ?
>
> I would like to avoid blocking calcite development for too long.
>
>
> On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei 
> wrote:
>
>> > Once this release is done, we should consider whether we should give
>> committers write access to SVN to avoid these issues in the future. I am
>> not sure if this is possible or if this is just the way ASF's infra is
>> set up, but it's worth a look.
>>
>> I cannot agree more. Thank you for pointing out, Francis.
>> (We can add some notes about it at least~~)
>>
>>
>>
>> Best,
>> Chunwei
>>
>>
>> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang > >
>> wrote:
>>
>> > Can someone please push the release artifacts for Andrei? I believe this
>> > is the same issue we had with the last release, where the RM is not a
>> > PMC member and doesn't have write access to SVN [1].
>> >
>> > Once this release is done, we should consider whether we should give
>> > committers write access to SVN to avoid these issues in the future. I am
>> > not sure if this is possible or if this is just the way ASF's infra is
>> > set up, but it's worth a look.
>> >
>> > Francis
>> >
>> > [1]
>> >
>> >
>> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
>> >
>> > On 13/08/2020 8:51 am, Andrei Sereda wrote:
>> > > Thanks, Stamatis. All seems to be working now.
>> > >
>> > > On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis <
>> zabe...@gmail.com>
>> > > wrote:
>> > >
>> > >> Hi Andrei,
>> > >>
>> > >> I uploaded your key to the file. Please check.
>> > >>
>> > >> Normally you don't need to be in the PMC to have access to the svn
>> repo.
>> > >> I don't know what went wrong and you were not able to push it
>> through.
>> > >>
>> > >> Best,
>> > >> Stamatis
>> > >>
>> > >> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda 
>> wrote:
>> > >>
>> > >>> Hello,
>> > >>>
>> > >>> Can somebody from PMC pls upload my public GPG key to KEYS
>> > >>> <https://dist.apache.org/repos/dist/release/calcite/KEYS> ? I don't
>> > have
>> > >>> permissions for that svn repo.
>> > >>>
>> > >>> I've sent an email to priv...@calcite.apache.org.
>> > >>>
>> > >>> Thanks,
>> > >>> Andrei.
>> > >>>
>> > >>> On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda 
>> > wrote:
>> > >>>
>> > >>>> Hi All,
>> > >>>>
>> > >>>> I plan to close the vote tomorrow (Aug 12th). If you still want to
>> > >>>> validate RC0 please do so before Wednesday.
>> > >>>>
>> > >>>> Regards,
>> > >>>> Andrei.
>> > >>>>
>> > >>>> On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda 
>> > >> wrote:
>> > >>>>
>> > >>>>> Thanks, Julian, for the hint. I'll update the KEYS file.
>> > >>>>>
>> > >>>>> On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde <
>> jhyde.apa...@gmail.com
>> > >
>> > >>>>> wrote:
>> > >>>>>
>> > >>>>>> Andrei,
>> > >>>>>>
>> > >>>>>> Your key’s signature appears in KEYS because you signed
>> Stamatis’s
>> > >> key.
>> > >>>>>> But your key isn’t actually defined in the file. After I imported
>> > the
>> > >>> file,
>> > >>>>>> your key was still ‘unknown’ according to gpg.
>> > >>>>>>
>> > >>>>>> Julian
>> > >>>>>>
>> > >>

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-13 Thread Andrei Sereda
Can someone from PMC pls publish the release ?  Or maybe contact INFRA
about svn permissions for committers vs PMCs ?

I would like to avoid blocking calcite development for too long.


On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei  wrote:

> > Once this release is done, we should consider whether we should give
> committers write access to SVN to avoid these issues in the future. I am
> not sure if this is possible or if this is just the way ASF's infra is
> set up, but it's worth a look.
>
> I cannot agree more. Thank you for pointing out, Francis.
> (We can add some notes about it at least~~)
>
>
>
> Best,
> Chunwei
>
>
> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang 
> wrote:
>
> > Can someone please push the release artifacts for Andrei? I believe this
> > is the same issue we had with the last release, where the RM is not a
> > PMC member and doesn't have write access to SVN [1].
> >
> > Once this release is done, we should consider whether we should give
> > committers write access to SVN to avoid these issues in the future. I am
> > not sure if this is possible or if this is just the way ASF's infra is
> > set up, but it's worth a look.
> >
> > Francis
> >
> > [1]
> >
> >
> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
> >
> > On 13/08/2020 8:51 am, Andrei Sereda wrote:
> > > Thanks, Stamatis. All seems to be working now.
> > >
> > > On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis  >
> > > wrote:
> > >
> > >> Hi Andrei,
> > >>
> > >> I uploaded your key to the file. Please check.
> > >>
> > >> Normally you don't need to be in the PMC to have access to the svn
> repo.
> > >> I don't know what went wrong and you were not able to push it through.
> > >>
> > >> Best,
> > >> Stamatis
> > >>
> > >> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda 
> wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> Can somebody from PMC pls upload my public GPG key to KEYS
> > >>> <https://dist.apache.org/repos/dist/release/calcite/KEYS> ? I don't
> > have
> > >>> permissions for that svn repo.
> > >>>
> > >>> I've sent an email to priv...@calcite.apache.org.
> > >>>
> > >>> Thanks,
> > >>> Andrei.
> > >>>
> > >>> On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda 
> > wrote:
> > >>>
> > >>>> Hi All,
> > >>>>
> > >>>> I plan to close the vote tomorrow (Aug 12th). If you still want to
> > >>>> validate RC0 please do so before Wednesday.
> > >>>>
> > >>>> Regards,
> > >>>> Andrei.
> > >>>>
> > >>>> On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda 
> > >> wrote:
> > >>>>
> > >>>>> Thanks, Julian, for the hint. I'll update the KEYS file.
> > >>>>>
> > >>>>> On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde <
> jhyde.apa...@gmail.com
> > >
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Andrei,
> > >>>>>>
> > >>>>>> Your key’s signature appears in KEYS because you signed Stamatis’s
> > >> key.
> > >>>>>> But your key isn’t actually defined in the file. After I imported
> > the
> > >>> file,
> > >>>>>> your key was still ‘unknown’ according to gpg.
> > >>>>>>
> > >>>>>> Julian
> > >>>>>>
> > >>>>>>> On Aug 11, 2020, at 8:04 AM, Andrei Sereda 
> > >> wrote:
> > >>>>>>>
> > >>>>>>> 
> > >>>>>>>>
> > >>>>>>>> * Andrei, I don’t think your key is in KEYS. Be sure to add it
> > >>> before
> > >>>>>> the
> > >>>>>>> release announcement.
> > >>>>>>>
> > >>>>>>> I see my signing key in KEYS
> > >>>>>>> $ curl -s
> https://dist.apache.org/repos/dist/release/calcite/KEYS
> > >> |
> > >>>>>> grep
> > >>>>>>> sereda
> > &

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-12 Thread Andrei Sereda
Thanks, Stamatis. All seems to be working now.

On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis 
wrote:

> Hi Andrei,
>
> I uploaded your key to the file. Please check.
>
> Normally you don't need to be in the PMC to have access to the svn repo.
> I don't know what went wrong and you were not able to push it through.
>
> Best,
> Stamatis
>
> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda  wrote:
>
> > Hello,
> >
> > Can somebody from PMC pls upload my public GPG key to KEYS
> > <https://dist.apache.org/repos/dist/release/calcite/KEYS> ? I don't have
> > permissions for that svn repo.
> >
> > I've sent an email to priv...@calcite.apache.org.
> >
> > Thanks,
> > Andrei.
> >
> > On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda  wrote:
> >
> > > Hi All,
> > >
> > > I plan to close the vote tomorrow (Aug 12th). If you still want to
> > > validate RC0 please do so before Wednesday.
> > >
> > > Regards,
> > > Andrei.
> > >
> > > On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda 
> wrote:
> > >
> > >> Thanks, Julian, for the hint. I'll update the KEYS file.
> > >>
> > >> On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde 
> > >> wrote:
> > >>
> > >>> Andrei,
> > >>>
> > >>> Your key’s signature appears in KEYS because you signed Stamatis’s
> key.
> > >>> But your key isn’t actually defined in the file. After I imported the
> > file,
> > >>> your key was still ‘unknown’ according to gpg.
> > >>>
> > >>> Julian
> > >>>
> > >>> > On Aug 11, 2020, at 8:04 AM, Andrei Sereda 
> wrote:
> > >>> >
> > >>> > 
> > >>> >>
> > >>> >> * Andrei, I don’t think your key is in KEYS. Be sure to add it
> > before
> > >>> the
> > >>> > release announcement.
> > >>> >
> > >>> > I see my signing key in KEYS
> > >>> > $ curl -s https://dist.apache.org/repos/dist/release/calcite/KEYS
> |
> > >>> grep
> > >>> > sereda
> > >>> > sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE
> SIGNING
> > >>> KEY) <
> > >>> > ser...@apache.org>
> > >>> > sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE
> SIGNING
> > >>> KEY) <
> > >>> > ser...@apache.org>
> > >>> >
> > >>> >> * There are several files in the source distro that are not in
> git:
> > an
> > >>> > empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
> > >>> > Yes you're right. I presume you're still OK with RC0 (judging by
> your
> > >>> +1) ?
> > >>> >
> > >>> >
> > >>> >> On Tue, Aug 11, 2020 at 5:53 AM Julian Hyde <
> jhyde.apa...@gmail.com
> > >
> > >>> wrote:
> > >>> >>
> > >>> >> +1 (binding)
> > >>> >>
> > >>> >> Checked keys, hashes, LICENSE, NOTICE, README; compiled and ran
> > tests
> > >>> on
> > >>> >> Ubuntu/JDK 14; ran RAT.
> > >>> >>
> > >>> >> * Andrei, I don’t think your key is in KEYS. Be sure to add it
> > before
> > >>> the
> > >>> >> release announcement.
> > >>> >>
> > >>> >> * There are several files in the source distro that are not in
> git:
> > an
> > >>> >> empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
> > >>> >>
> > >>> >> Julian
> > >>> >>
> > >>> >>
> > >>> >>> On Aug 11, 2020, at 2:33 AM, Stamatis Zampetakis <
> > zabe...@gmail.com>
> > >>> >> wrote:
> > >>> >>>
> > >>> >>> If I remember well the site preview is not implemented so it is
> > >>> normal
> > >>> >> that
> > >>> >>> links are broken.
> > >>> >>> I don't know if this has changed recently but if not I think we
> > >>> should
> > >>> >>> remove the site preview links from the draft email to avoid
> > >>> confusion.
> > >>&

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-12 Thread Andrei Sereda
Hello,

Can somebody from PMC pls upload my public GPG key to KEYS
<https://dist.apache.org/repos/dist/release/calcite/KEYS> ? I don't have
permissions for that svn repo.

I've sent an email to priv...@calcite.apache.org.

Thanks,
Andrei.

On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda  wrote:

> Hi All,
>
> I plan to close the vote tomorrow (Aug 12th). If you still want to
> validate RC0 please do so before Wednesday.
>
> Regards,
> Andrei.
>
> On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda  wrote:
>
>> Thanks, Julian, for the hint. I'll update the KEYS file.
>>
>> On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde 
>> wrote:
>>
>>> Andrei,
>>>
>>> Your key’s signature appears in KEYS because you signed Stamatis’s key.
>>> But your key isn’t actually defined in the file. After I imported the file,
>>> your key was still ‘unknown’ according to gpg.
>>>
>>> Julian
>>>
>>> > On Aug 11, 2020, at 8:04 AM, Andrei Sereda  wrote:
>>> >
>>> > 
>>> >>
>>> >> * Andrei, I don’t think your key is in KEYS. Be sure to add it before
>>> the
>>> > release announcement.
>>> >
>>> > I see my signing key in KEYS
>>> > $ curl -s https://dist.apache.org/repos/dist/release/calcite/KEYS |
>>> grep
>>> > sereda
>>> > sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE SIGNING
>>> KEY) <
>>> > ser...@apache.org>
>>> > sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE SIGNING
>>> KEY) <
>>> > ser...@apache.org>
>>> >
>>> >> * There are several files in the source distro that are not in git: an
>>> > empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
>>> > Yes you're right. I presume you're still OK with RC0 (judging by your
>>> +1) ?
>>> >
>>> >
>>> >> On Tue, Aug 11, 2020 at 5:53 AM Julian Hyde 
>>> wrote:
>>> >>
>>> >> +1 (binding)
>>> >>
>>> >> Checked keys, hashes, LICENSE, NOTICE, README; compiled and ran tests
>>> on
>>> >> Ubuntu/JDK 14; ran RAT.
>>> >>
>>> >> * Andrei, I don’t think your key is in KEYS. Be sure to add it before
>>> the
>>> >> release announcement.
>>> >>
>>> >> * There are several files in the source distro that are not in git: an
>>> >> empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
>>> >>
>>> >> Julian
>>> >>
>>> >>
>>> >>> On Aug 11, 2020, at 2:33 AM, Stamatis Zampetakis 
>>> >> wrote:
>>> >>>
>>> >>> If I remember well the site preview is not implemented so it is
>>> normal
>>> >> that
>>> >>> links are broken.
>>> >>> I don't know if this has changed recently but if not I think we
>>> should
>>> >>> remove the site preview links from the draft email to avoid
>>> confusion.
>>> >>>
>>> >>> Best,
>>> >>> Stamatis
>>> >>>
>>> >>>> On Mon, Aug 10, 2020 at 8:08 PM Andrei Sereda 
>>> wrote:
>>> >>>
>>> >>>> Yes I'm aware that for some reason site artifact wasn't built /
>>> >> uploaded.
>>> >>>>
>>> >>>> Meanwhile here are the release notes:
>>> >>>>
>>> >>>>
>>> >>
>>> https://github.com/apache/calcite/blob/calcite-1.25.0-rc0/site/_docs/history.md
>>> >>>>
>>> >>>> I'll double-check the build script / instructions, maybe I have
>>> missed
>>> >>>> something.
>>> >>>>
>>> >>>> On Mon, Aug 10, 2020 at 12:59 PM Haisheng Yuan 
>>> >> wrote:
>>> >>>>
>>> >>>>> +1 (binding)
>>> >>>>>
>>> >>>>> Environment:
>>> >>>>> Mac OS X 10.15.1 , JDK 1.8.0_162
>>> >>>>> - Ran unit tests (./gradlew build), OK
>>> >>>>> - Checked release notes, CALCITE-4156, CALCITE-4022 CALCITE-4115
>>> >>>>> CALCITE-4129 CALCITE-4111 are not part of Build an

[RESULT] [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-12 Thread Andrei Sereda
Thanks to everyone who has tested the release candidate and given their
comments and votes.

The tally is as follows.

4 binding +1s:
 * Francis Chuang
 * Michael Mior
 * Haisheng Yuan
 * Julian Hyde

7 non-binding +1s:
 * Enrico Olivelli
 * Rui Wang
 * chunwei
 * Ruben Q L
 * Anton Haidai
 * xzh
 * Andrei Sereda

No 0s or -1s.

Therefore I am delighted to announce that the proposal to release Apache
Calcite 1.25.0 has passed.

Thanks everyone. We’ll now roll the release out to the mirrors.

I will also update release notes (in separate commit) to better
reflect 1.25.0 changes.

Please refrain from modifying master until release is over. Separate
notification will be sent once commits are allowed.

Andrei


Re: [ANNOUNCE] Ruben Quesada Lopez joins Calcite PMC

2020-08-12 Thread Andrei Sereda
Congratulations, Ruben!

On Wed, Aug 12, 2020 at 1:21 PM Rui Wang  wrote:

> Congrats, Ruben! Well deserved!
>
>
>
> -Rui
>
> On Wed, Aug 12, 2020 at 9:24 AM Enrico Olivelli 
> wrote:
>
> > Congrats Ruben!
> >
> > Enrico
> >
> > Il Mer 12 Ago 2020, 18:05 Michael Mior  ha scritto:
> >
> > > Congrats Reuben!
> > >
> > > --
> > > Michael Mior
> > > mm...@apache.org
> > >
> > > Le mer. 12 août 2020 à 09:32, Ruben Q L  a écrit :
> > > >
> > > > Thanks everyone!
> > > > It is an honor to join the Calcite PMC.
> > > >
> > > > Best regards,
> > > > Ruben
> > > >
> > > >
> > > > Le mer. 12 août 2020 à 03:03, Forward Xu  a
> > > écrit :
> > > >
> > > > > Congrats, Ruben!
> > > > >
> > > > >
> > > > > Best
> > > > >
> > > > > Forward
> > > > >
> > > > > XING JIN  于2020年8月12日周三 上午8:58写道:
> > > > >
> > > > > > Congrats, Ruben!
> > > > > >
> > > > > > 953396112 <953396...@qq.com> 于2020年8月12日周三 上午7:47写道:
> > > > > >
> > > > > > > Congratulations,Ruben!
> > > > > > >
> > > > > > >
> > > > > > > xzh
> > > > > > > --原始邮件--
> > > > > > > 发件人:
> > > > > > >   "dev"
> > > > > > >
>  <
> > > > > > > zabe...@gmail.com;
> > > > > > > 发送时间:2020年8月12日(星期三) 凌晨5:53
> > > > > > > 收件人:"dev" > > > > > >
> > > > > > > 主题:[ANNOUNCE] Ruben Quesada Lopez joins Calcite PMC
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I'm pleased to announce that Ruben has accepted an invitation
> to
> > > > > > > join the Calcite PMC. Ruben has been a consistent and helpful
> > > > > > > figure in the Calcite community for which we are very grateful.
> > We
> > > > > > > look forward to the continued contributions and support.
> > > > > > >
> > > > > > > Please join me in congratulating Ruben!
> > > > > > >
> > > > > > > - Stamatis (on behalf of the Calcite PMC)
> > > > > >
> > > > >
> > >
> >
>


Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-11 Thread Andrei Sereda
Hi All,

I plan to close the vote tomorrow (Aug 12th). If you still want to validate
RC0 please do so before Wednesday.

Regards,
Andrei.

On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda  wrote:

> Thanks, Julian, for the hint. I'll update the KEYS file.
>
> On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde 
> wrote:
>
>> Andrei,
>>
>> Your key’s signature appears in KEYS because you signed Stamatis’s key.
>> But your key isn’t actually defined in the file. After I imported the file,
>> your key was still ‘unknown’ according to gpg.
>>
>> Julian
>>
>> > On Aug 11, 2020, at 8:04 AM, Andrei Sereda  wrote:
>> >
>> > 
>> >>
>> >> * Andrei, I don’t think your key is in KEYS. Be sure to add it before
>> the
>> > release announcement.
>> >
>> > I see my signing key in KEYS
>> > $ curl -s https://dist.apache.org/repos/dist/release/calcite/KEYS |
>> grep
>> > sereda
>> > sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE SIGNING
>> KEY) <
>> > ser...@apache.org>
>> > sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE SIGNING
>> KEY) <
>> > ser...@apache.org>
>> >
>> >> * There are several files in the source distro that are not in git: an
>> > empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
>> > Yes you're right. I presume you're still OK with RC0 (judging by your
>> +1) ?
>> >
>> >
>> >> On Tue, Aug 11, 2020 at 5:53 AM Julian Hyde 
>> wrote:
>> >>
>> >> +1 (binding)
>> >>
>> >> Checked keys, hashes, LICENSE, NOTICE, README; compiled and ran tests
>> on
>> >> Ubuntu/JDK 14; ran RAT.
>> >>
>> >> * Andrei, I don’t think your key is in KEYS. Be sure to add it before
>> the
>> >> release announcement.
>> >>
>> >> * There are several files in the source distro that are not in git: an
>> >> empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
>> >>
>> >> Julian
>> >>
>> >>
>> >>> On Aug 11, 2020, at 2:33 AM, Stamatis Zampetakis 
>> >> wrote:
>> >>>
>> >>> If I remember well the site preview is not implemented so it is normal
>> >> that
>> >>> links are broken.
>> >>> I don't know if this has changed recently but if not I think we should
>> >>> remove the site preview links from the draft email to avoid confusion.
>> >>>
>> >>> Best,
>> >>> Stamatis
>> >>>
>> >>>> On Mon, Aug 10, 2020 at 8:08 PM Andrei Sereda 
>> wrote:
>> >>>
>> >>>> Yes I'm aware that for some reason site artifact wasn't built /
>> >> uploaded.
>> >>>>
>> >>>> Meanwhile here are the release notes:
>> >>>>
>> >>>>
>> >>
>> https://github.com/apache/calcite/blob/calcite-1.25.0-rc0/site/_docs/history.md
>> >>>>
>> >>>> I'll double-check the build script / instructions, maybe I have
>> missed
>> >>>> something.
>> >>>>
>> >>>> On Mon, Aug 10, 2020 at 12:59 PM Haisheng Yuan 
>> >> wrote:
>> >>>>
>> >>>>> +1 (binding)
>> >>>>>
>> >>>>> Environment:
>> >>>>> Mac OS X 10.15.1 , JDK 1.8.0_162
>> >>>>> - Ran unit tests (./gradlew build), OK
>> >>>>> - Checked release notes, CALCITE-4156, CALCITE-4022 CALCITE-4115
>> >>>>> CALCITE-4129 CALCITE-4111 are not part of Build and test suite
>> changes,
>> >>>>> those can be updated after release.
>> >>>>>
>> >>>>> - Haisheng
>> >>>>>
>> >>>>> On 2020/08/09 03:22:28, Andrei Sereda  wrote:
>> >>>>>> Hi all,
>> >>>>>>
>> >>>>>> I have created a build for Apache Calcite 1.25.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
>> >>>>>>
>> >>

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-11 Thread Andrei Sereda
Thanks, Julian, for the hint. I'll update the KEYS file.

On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde  wrote:

> Andrei,
>
> Your key’s signature appears in KEYS because you signed Stamatis’s key.
> But your key isn’t actually defined in the file. After I imported the file,
> your key was still ‘unknown’ according to gpg.
>
> Julian
>
> > On Aug 11, 2020, at 8:04 AM, Andrei Sereda  wrote:
> >
> > 
> >>
> >> * Andrei, I don’t think your key is in KEYS. Be sure to add it before
> the
> > release announcement.
> >
> > I see my signing key in KEYS
> > $ curl -s https://dist.apache.org/repos/dist/release/calcite/KEYS | grep
> > sereda
> > sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE SIGNING
> KEY) <
> > ser...@apache.org>
> > sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE SIGNING
> KEY) <
> > ser...@apache.org>
> >
> >> * There are several files in the source distro that are not in git: an
> > empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
> > Yes you're right. I presume you're still OK with RC0 (judging by your
> +1) ?
> >
> >
> >> On Tue, Aug 11, 2020 at 5:53 AM Julian Hyde 
> wrote:
> >>
> >> +1 (binding)
> >>
> >> Checked keys, hashes, LICENSE, NOTICE, README; compiled and ran tests on
> >> Ubuntu/JDK 14; ran RAT.
> >>
> >> * Andrei, I don’t think your key is in KEYS. Be sure to add it before
> the
> >> release announcement.
> >>
> >> * There are several files in the source distro that are not in git: an
> >> empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
> >>
> >> Julian
> >>
> >>
> >>> On Aug 11, 2020, at 2:33 AM, Stamatis Zampetakis 
> >> wrote:
> >>>
> >>> If I remember well the site preview is not implemented so it is normal
> >> that
> >>> links are broken.
> >>> I don't know if this has changed recently but if not I think we should
> >>> remove the site preview links from the draft email to avoid confusion.
> >>>
> >>> Best,
> >>> Stamatis
> >>>
> >>>> On Mon, Aug 10, 2020 at 8:08 PM Andrei Sereda 
> wrote:
> >>>
> >>>> Yes I'm aware that for some reason site artifact wasn't built /
> >> uploaded.
> >>>>
> >>>> Meanwhile here are the release notes:
> >>>>
> >>>>
> >>
> https://github.com/apache/calcite/blob/calcite-1.25.0-rc0/site/_docs/history.md
> >>>>
> >>>> I'll double-check the build script / instructions, maybe I have missed
> >>>> something.
> >>>>
> >>>> On Mon, Aug 10, 2020 at 12:59 PM Haisheng Yuan 
> >> wrote:
> >>>>
> >>>>> +1 (binding)
> >>>>>
> >>>>> Environment:
> >>>>> Mac OS X 10.15.1 , JDK 1.8.0_162
> >>>>> - Ran unit tests (./gradlew build), OK
> >>>>> - Checked release notes, CALCITE-4156, CALCITE-4022 CALCITE-4115
> >>>>> CALCITE-4129 CALCITE-4111 are not part of Build and test suite
> changes,
> >>>>> those can be updated after release.
> >>>>>
> >>>>> - Haisheng
> >>>>>
> >>>>> On 2020/08/09 03:22:28, Andrei Sereda  wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I have created a build for Apache Calcite 1.25.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=68b02dfd4af15bc94a91a0cd2a30655d04439555
> >>>>>>
> >>>>>> Its hash is 68b02dfd4af15bc94a91a0cd2a30655d04439555
> >>>>>>
> >>>>>> Tag:
> >>>>>> https://github.com/apache/calcite/tree/calcite-1.25.0-rc0
> >>>>>>
> >>>>>> The artifacts to be voted on are located here:
> >>>>>>
> >>>

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-11 Thread Andrei Sereda
> * Andrei, I don’t think your key is in KEYS. Be sure to add it before the
release announcement.

I see my signing key in KEYS
$ curl -s https://dist.apache.org/repos/dist/release/calcite/KEYS | grep
sereda
sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE SIGNING KEY) <
ser...@apache.org>
sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE SIGNING KEY) <
ser...@apache.org>

> * There are several files in the source distro that are not in git: an
empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
Yes you're right. I presume you're still OK with RC0 (judging by your +1) ?


On Tue, Aug 11, 2020 at 5:53 AM Julian Hyde  wrote:

> +1 (binding)
>
> Checked keys, hashes, LICENSE, NOTICE, README; compiled and ran tests on
> Ubuntu/JDK 14; ran RAT.
>
> * Andrei, I don’t think your key is in KEYS. Be sure to add it before the
> release announcement.
>
> * There are several files in the source distro that are not in git: an
> empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
>
> Julian
>
>
> > On Aug 11, 2020, at 2:33 AM, Stamatis Zampetakis 
> wrote:
> >
> > If I remember well the site preview is not implemented so it is normal
> that
> > links are broken.
> > I don't know if this has changed recently but if not I think we should
> > remove the site preview links from the draft email to avoid confusion.
> >
> > Best,
> > Stamatis
> >
> > On Mon, Aug 10, 2020 at 8:08 PM Andrei Sereda  wrote:
> >
> >> Yes I'm aware that for some reason site artifact wasn't built /
> uploaded.
> >>
> >> Meanwhile here are the release notes:
> >>
> >>
> https://github.com/apache/calcite/blob/calcite-1.25.0-rc0/site/_docs/history.md
> >>
> >> I'll double-check the build script / instructions, maybe I have missed
> >> something.
> >>
> >> On Mon, Aug 10, 2020 at 12:59 PM Haisheng Yuan 
> wrote:
> >>
> >>> +1 (binding)
> >>>
> >>> Environment:
> >>> Mac OS X 10.15.1 , JDK 1.8.0_162
> >>> - Ran unit tests (./gradlew build), OK
> >>> - Checked release notes, CALCITE-4156, CALCITE-4022 CALCITE-4115
> >>> CALCITE-4129 CALCITE-4111 are not part of Build and test suite changes,
> >>> those can be updated after release.
> >>>
> >>> - Haisheng
> >>>
> >>> On 2020/08/09 03:22:28, Andrei Sereda  wrote:
> >>>> Hi all,
> >>>>
> >>>> I have created a build for Apache Calcite 1.25.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=68b02dfd4af15bc94a91a0cd2a30655d04439555
> >>>>
> >>>> Its hash is 68b02dfd4af15bc94a91a0cd2a30655d04439555
> >>>>
> >>>> Tag:
> >>>> https://github.com/apache/calcite/tree/calcite-1.25.0-rc0
> >>>>
> >>>> The artifacts to be voted on are located here:
> >>>>
> >>
> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.25.0-rc0
> >>>> (revision 40922)
> >>>>
> >>>> 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:
> >>>>
> >>>
> >>
> a5e61bd93657a274ee8a1d1ecbde68e3e471fd27b85bea179991b372f094ae3cdf692672245506a08b996534f9136be26569de81af2bb7d8f026799313957e87
> >>>> *apache-calcite-1.25.0-src.tar.gz
> >>>>
> >>>> A staged Maven repository is available for review at:
> >>>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecalcite-1097/org/apache/calcite/
> >>>>
> >>>> Release artifacts are signed with the following key:
> >>>> https://people.apache.org/keys/committer/sereda.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.25.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.25.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 (non binding)
> >>>>
> >>>
> >>
>
>


Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

2020-08-10 Thread Andrei Sereda
Yes I'm aware that for some reason site artifact wasn't built / uploaded.

Meanwhile here are the release notes:
https://github.com/apache/calcite/blob/calcite-1.25.0-rc0/site/_docs/history.md

I'll double-check the build script / instructions, maybe I have missed
something.

On Mon, Aug 10, 2020 at 12:59 PM Haisheng Yuan  wrote:

> +1 (binding)
>
> Environment:
> Mac OS X 10.15.1 , JDK 1.8.0_162
> - Ran unit tests (./gradlew build), OK
> - Checked release notes, CALCITE-4156, CALCITE-4022 CALCITE-4115
> CALCITE-4129 CALCITE-4111 are not part of Build and test suite changes,
> those can be updated after release.
>
> - Haisheng
>
> On 2020/08/09 03:22:28, Andrei Sereda  wrote:
> > Hi all,
> >
> > I have created a build for Apache Calcite 1.25.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=68b02dfd4af15bc94a91a0cd2a30655d04439555
> >
> > Its hash is 68b02dfd4af15bc94a91a0cd2a30655d04439555
> >
> > Tag:
> > https://github.com/apache/calcite/tree/calcite-1.25.0-rc0
> >
> > The artifacts to be voted on are located here:
> > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.25.0-rc0
> > (revision 40922)
> >
> > 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:
> >
> a5e61bd93657a274ee8a1d1ecbde68e3e471fd27b85bea179991b372f094ae3cdf692672245506a08b996534f9136be26569de81af2bb7d8f026799313957e87
> > *apache-calcite-1.25.0-src.tar.gz
> >
> > A staged Maven repository is available for review at:
> >
> https://repository.apache.org/content/repositories/orgapachecalcite-1097/org/apache/calcite/
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/sereda.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.25.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.25.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 (non binding)
> >
>


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

2020-08-08 Thread Andrei Sereda
Hi all,

I have created a build for Apache Calcite 1.25.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=68b02dfd4af15bc94a91a0cd2a30655d04439555

Its hash is 68b02dfd4af15bc94a91a0cd2a30655d04439555

Tag:
https://github.com/apache/calcite/tree/calcite-1.25.0-rc0

The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.25.0-rc0
(revision 40922)

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:
a5e61bd93657a274ee8a1d1ecbde68e3e471fd27b85bea179991b372f094ae3cdf692672245506a08b996534f9136be26569de81af2bb7d8f026799313957e87
*apache-calcite-1.25.0-src.tar.gz

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1097/org/apache/calcite/

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/sereda.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.25.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.25.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 (non binding)


Re: [DISCUSS] Towards Calcite 1.25.0

2020-08-08 Thread Andrei Sereda
I would say yes.

On Sat, Aug 8, 2020, 13:32 Rui Wang  wrote:

> Is the highlight section a right place for [1] as it has bigger impact?
>
>
> [1]
>
> https://github.com/apache/calcite/commit/19edf52c76c6a1507721f5bd37f2a33497aa0c4c
>
> -Rui
>
> On Fri, Aug 7, 2020 at 9:48 PM Andrei Sereda  wrote:
>
> > Hello,
> >
> > Does anybody want to mention any highlights for 1.25 besides removal of
> > deprecated methods  ?
> >
> > Currently it says:
> > ===
> > This release comes shortly after 1.24.0 (in just two weeks) and removes
> > methods which were deprecated in the previous version.
> > ===
> >
> > Thanks,
> > Andrei.
> >
> > On Fri, Aug 7, 2020 at 11:12 AM Andrei Sereda  wrote:
> >
> > > Hello,
> > >
> > > I'm starting the release today. If there are some PRs which you would
> > like
> > > to be included in 1.25 please let me know ASAP.
> > >
> > > This should be a quick release mostly for CALCITE-4136
> > >
> > > Thanks,
> > > Andrei.
> > >
> > > On Fri, Aug 7, 2020 at 4:33 AM Julian Hyde  wrote:
> > >
> > >> Andrei,
> > >>
> > >> We agreed that this would be a quick release. Above I mentioned Aug
> > >> 8th as a target, and it's Aug 7th already. Can you start moving the
> > >> release process along, please.
> > >>
> > >> Julian
> > >>
> > >> On Fri, Jul 24, 2020 at 2:23 PM Andrei Sereda 
> wrote:
> > >> >
> > >> > Julian,
> > >> >
> > >> > Yes this time I should have enough cycles for the release.
> > >> >
> > >> > Also, I think Danny did the heavy lifting with 1.22 since it wasn't
> an
> > >> easy
> > >> > one.
> > >> >
> > >> > Andrei.
> > >> >
> > >> > On Fri, Jul 24, 2020, 16:16 Julian Hyde 
> > wrote:
> > >> >
> > >> > > Andrei,
> > >> > >
> > >> > > That would be great. Last time I recall you had a crunch at
> $dayjob
> > >> that
> > >> > > didn’t leave you with enough cycles to be release manager. I think
> > >> this
> > >> > > release should be timely, so if that is a concern this time
> around,
> > >> let us
> > >> > > know.
> > >> > >
> > >> > > (Maybe the fact that this release is very time-boxed will make
> that
> > >> less
> > >> > > of a risk. I really think we could get this done in by Aug 8 -
> i.e.
> > 2
> > >> weeks
> > >> > > - if we focus.)
> > >> > >
> > >> > > Julian
> > >> > >
> > >> > >
> > >> > > > On Jul 24, 2020, at 9:57 AM, Andrei Sereda 
> > >> wrote:
> > >> > > >
> > >> > > > It should be me.
> > >> > > >
> > >> > > > I swapped the 1.22 release with Danny Chen who was supposed to
> be
> > >> release
> > >> > > > manager for 1.25
> > >> > > >
> > >> > > > On Fri, Jul 24, 2020 at 12:52 PM Haisheng Yuan <
> hy...@apache.org>
> > >> wrote:
> > >> > > >
> > >> > > >> Do we have release manager for v1.25.0?
> > >> > > >>
> > >> > > >>
> > >> > > >> On 2020/07/23 17:15:12, Julian Hyde 
> > >> wrote:
> > >> > > >>> The release vote for 1.24 RC0 just passed [1], and it will be
> > >> released
> > >> > > >> shortly.
> > >> > > >>>
> > >> > > >>> We planned that release 1.24 is a transitional release, and
> 1.25
> > >> will
> > >> > > >> follow soon afterwards. 1.24 deprecates some APIs that we
> intend
> > to
> > >> > > remove
> > >> > > >> in 1.25. We had to make the release so that people can see that
> > >> the APIs
> > >> > > >> are deprecated, and replace them with the new versions.
> > >> > > >>>
> > >> > > >>> During the release vote we ran into 4136 [2]. This is a real
> > bug,
> > >> > > caused
> > >> > > >> in part by the API changes to deprecate APIs (and provide
> > long-term
> > >> > > >> replacements) and in part caused by 4079 [3], the real bug that
> > we
> > >> are
> > >> > > >> trying to solve in 1.25.
> > >> > > >>>
> > >> > > >>> So, it is important that we release 1.25 soon, and that it
> > solves
> > >> all
> > >> > > of
> > >> > > >> these problems. I don’t know whether people will perceive 1.24
> > as a
> > >> > > release
> > >> > > >> “lower than our usual quality” (even though there are good
> > reasons
> > >> for
> > >> > > it)
> > >> > > >> but 1.25 needs to be back to the usual quality.
> > >> > > >>>
> > >> > > >>> Julian
> > >> > > >>>
> > >> > > >>> [1] https://issues.apache.org/jira/browse/CALCITE-4117 <
> > >> > > >> https://issues.apache.org/jira/browse/CALCITE-4117>
> > >> > > >>>
> > >> > > >>> [2] https://issues.apache.org/jira/browse/CALCITE-4136 <
> > >> > > >> https://issues.apache.org/jira/browse/CALCITE-4136>
> > >> > > >>>
> > >> > > >>> [3] https://issues.apache.org/jira/browse/CALCITE-4079 <
> > >> > > >> https://issues.apache.org/jira/browse/CALCITE-4079>
> > >> > > >>
> > >> > >
> > >> > >
> > >>
> > >
> >
>


Re: [DISCUSS] Towards Calcite 1.25.0

2020-08-07 Thread Andrei Sereda
Hello,

Does anybody want to mention any highlights for 1.25 besides removal of
deprecated methods  ?

Currently it says:
===
This release comes shortly after 1.24.0 (in just two weeks) and removes
methods which were deprecated in the previous version.
===

Thanks,
Andrei.

On Fri, Aug 7, 2020 at 11:12 AM Andrei Sereda  wrote:

> Hello,
>
> I'm starting the release today. If there are some PRs which you would like
> to be included in 1.25 please let me know ASAP.
>
> This should be a quick release mostly for CALCITE-4136
>
> Thanks,
> Andrei.
>
> On Fri, Aug 7, 2020 at 4:33 AM Julian Hyde  wrote:
>
>> Andrei,
>>
>> We agreed that this would be a quick release. Above I mentioned Aug
>> 8th as a target, and it's Aug 7th already. Can you start moving the
>> release process along, please.
>>
>> Julian
>>
>> On Fri, Jul 24, 2020 at 2:23 PM Andrei Sereda  wrote:
>> >
>> > Julian,
>> >
>> > Yes this time I should have enough cycles for the release.
>> >
>> > Also, I think Danny did the heavy lifting with 1.22 since it wasn't an
>> easy
>> > one.
>> >
>> > Andrei.
>> >
>> > On Fri, Jul 24, 2020, 16:16 Julian Hyde  wrote:
>> >
>> > > Andrei,
>> > >
>> > > That would be great. Last time I recall you had a crunch at $dayjob
>> that
>> > > didn’t leave you with enough cycles to be release manager. I think
>> this
>> > > release should be timely, so if that is a concern this time around,
>> let us
>> > > know.
>> > >
>> > > (Maybe the fact that this release is very time-boxed will make that
>> less
>> > > of a risk. I really think we could get this done in by Aug 8 - i.e. 2
>> weeks
>> > > - if we focus.)
>> > >
>> > > Julian
>> > >
>> > >
>> > > > On Jul 24, 2020, at 9:57 AM, Andrei Sereda 
>> wrote:
>> > > >
>> > > > It should be me.
>> > > >
>> > > > I swapped the 1.22 release with Danny Chen who was supposed to be
>> release
>> > > > manager for 1.25
>> > > >
>> > > > On Fri, Jul 24, 2020 at 12:52 PM Haisheng Yuan 
>> wrote:
>> > > >
>> > > >> Do we have release manager for v1.25.0?
>> > > >>
>> > > >>
>> > > >> On 2020/07/23 17:15:12, Julian Hyde 
>> wrote:
>> > > >>> The release vote for 1.24 RC0 just passed [1], and it will be
>> released
>> > > >> shortly.
>> > > >>>
>> > > >>> We planned that release 1.24 is a transitional release, and 1.25
>> will
>> > > >> follow soon afterwards. 1.24 deprecates some APIs that we intend to
>> > > remove
>> > > >> in 1.25. We had to make the release so that people can see that
>> the APIs
>> > > >> are deprecated, and replace them with the new versions.
>> > > >>>
>> > > >>> During the release vote we ran into 4136 [2]. This is a real bug,
>> > > caused
>> > > >> in part by the API changes to deprecate APIs (and provide long-term
>> > > >> replacements) and in part caused by 4079 [3], the real bug that we
>> are
>> > > >> trying to solve in 1.25.
>> > > >>>
>> > > >>> So, it is important that we release 1.25 soon, and that it solves
>> all
>> > > of
>> > > >> these problems. I don’t know whether people will perceive 1.24 as a
>> > > release
>> > > >> “lower than our usual quality” (even though there are good reasons
>> for
>> > > it)
>> > > >> but 1.25 needs to be back to the usual quality.
>> > > >>>
>> > > >>> Julian
>> > > >>>
>> > > >>> [1] https://issues.apache.org/jira/browse/CALCITE-4117 <
>> > > >> https://issues.apache.org/jira/browse/CALCITE-4117>
>> > > >>>
>> > > >>> [2] https://issues.apache.org/jira/browse/CALCITE-4136 <
>> > > >> https://issues.apache.org/jira/browse/CALCITE-4136>
>> > > >>>
>> > > >>> [3] https://issues.apache.org/jira/browse/CALCITE-4079 <
>> > > >> https://issues.apache.org/jira/browse/CALCITE-4079>
>> > > >>
>> > >
>> > >
>>
>


master locked during 1.25.0 release

2020-08-07 Thread Andrei Sereda
Hello,

Please avoid committing anything to master while 1.25.0 release is in
progress.

It will be unlocked after the voting / successful release.

Many thanks,
Andrei.


[jira] [Created] (CALCITE-4169) Release Calcite 1.25.0

2020-08-07 Thread Andrei Sereda (Jira)
Andrei Sereda created CALCITE-4169:
--

 Summary: Release Calcite 1.25.0
 Key: CALCITE-4169
 URL: https://issues.apache.org/jira/browse/CALCITE-4169
 Project: Calcite
  Issue Type: Task
Reporter: Andrei Sereda
Assignee: Andrei Sereda


Created for tracking 1.25.0 release 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [DISCUSS] Towards Calcite 1.25.0

2020-08-07 Thread Andrei Sereda
Hello,

I'm starting the release today. If there are some PRs which you would like
to be included in 1.25 please let me know ASAP.

This should be a quick release mostly for CALCITE-4136

Thanks,
Andrei.

On Fri, Aug 7, 2020 at 4:33 AM Julian Hyde  wrote:

> Andrei,
>
> We agreed that this would be a quick release. Above I mentioned Aug
> 8th as a target, and it's Aug 7th already. Can you start moving the
> release process along, please.
>
> Julian
>
> On Fri, Jul 24, 2020 at 2:23 PM Andrei Sereda  wrote:
> >
> > Julian,
> >
> > Yes this time I should have enough cycles for the release.
> >
> > Also, I think Danny did the heavy lifting with 1.22 since it wasn't an
> easy
> > one.
> >
> > Andrei.
> >
> > On Fri, Jul 24, 2020, 16:16 Julian Hyde  wrote:
> >
> > > Andrei,
> > >
> > > That would be great. Last time I recall you had a crunch at $dayjob
> that
> > > didn’t leave you with enough cycles to be release manager. I think this
> > > release should be timely, so if that is a concern this time around,
> let us
> > > know.
> > >
> > > (Maybe the fact that this release is very time-boxed will make that
> less
> > > of a risk. I really think we could get this done in by Aug 8 - i.e. 2
> weeks
> > > - if we focus.)
> > >
> > > Julian
> > >
> > >
> > > > On Jul 24, 2020, at 9:57 AM, Andrei Sereda  wrote:
> > > >
> > > > It should be me.
> > > >
> > > > I swapped the 1.22 release with Danny Chen who was supposed to be
> release
> > > > manager for 1.25
> > > >
> > > > On Fri, Jul 24, 2020 at 12:52 PM Haisheng Yuan 
> wrote:
> > > >
> > > >> Do we have release manager for v1.25.0?
> > > >>
> > > >>
> > > >> On 2020/07/23 17:15:12, Julian Hyde  wrote:
> > > >>> The release vote for 1.24 RC0 just passed [1], and it will be
> released
> > > >> shortly.
> > > >>>
> > > >>> We planned that release 1.24 is a transitional release, and 1.25
> will
> > > >> follow soon afterwards. 1.24 deprecates some APIs that we intend to
> > > remove
> > > >> in 1.25. We had to make the release so that people can see that the
> APIs
> > > >> are deprecated, and replace them with the new versions.
> > > >>>
> > > >>> During the release vote we ran into 4136 [2]. This is a real bug,
> > > caused
> > > >> in part by the API changes to deprecate APIs (and provide long-term
> > > >> replacements) and in part caused by 4079 [3], the real bug that we
> are
> > > >> trying to solve in 1.25.
> > > >>>
> > > >>> So, it is important that we release 1.25 soon, and that it solves
> all
> > > of
> > > >> these problems. I don’t know whether people will perceive 1.24 as a
> > > release
> > > >> “lower than our usual quality” (even though there are good reasons
> for
> > > it)
> > > >> but 1.25 needs to be back to the usual quality.
> > > >>>
> > > >>> Julian
> > > >>>
> > > >>> [1] https://issues.apache.org/jira/browse/CALCITE-4117 <
> > > >> https://issues.apache.org/jira/browse/CALCITE-4117>
> > > >>>
> > > >>> [2] https://issues.apache.org/jira/browse/CALCITE-4136 <
> > > >> https://issues.apache.org/jira/browse/CALCITE-4136>
> > > >>>
> > > >>> [3] https://issues.apache.org/jira/browse/CALCITE-4079 <
> > > >> https://issues.apache.org/jira/browse/CALCITE-4079>
> > > >>
> > >
> > >
>


Re: [DISCUSS] Towards Calcite 1.25.0

2020-07-24 Thread Andrei Sereda
Julian,

Yes this time I should have enough cycles for the release.

Also, I think Danny did the heavy lifting with 1.22 since it wasn't an easy
one.

Andrei.

On Fri, Jul 24, 2020, 16:16 Julian Hyde  wrote:

> Andrei,
>
> That would be great. Last time I recall you had a crunch at $dayjob that
> didn’t leave you with enough cycles to be release manager. I think this
> release should be timely, so if that is a concern this time around, let us
> know.
>
> (Maybe the fact that this release is very time-boxed will make that less
> of a risk. I really think we could get this done in by Aug 8 - i.e. 2 weeks
> - if we focus.)
>
> Julian
>
>
> > On Jul 24, 2020, at 9:57 AM, Andrei Sereda  wrote:
> >
> > It should be me.
> >
> > I swapped the 1.22 release with Danny Chen who was supposed to be release
> > manager for 1.25
> >
> > On Fri, Jul 24, 2020 at 12:52 PM Haisheng Yuan  wrote:
> >
> >> Do we have release manager for v1.25.0?
> >>
> >>
> >> On 2020/07/23 17:15:12, Julian Hyde  wrote:
> >>> The release vote for 1.24 RC0 just passed [1], and it will be released
> >> shortly.
> >>>
> >>> We planned that release 1.24 is a transitional release, and 1.25 will
> >> follow soon afterwards. 1.24 deprecates some APIs that we intend to
> remove
> >> in 1.25. We had to make the release so that people can see that the APIs
> >> are deprecated, and replace them with the new versions.
> >>>
> >>> During the release vote we ran into 4136 [2]. This is a real bug,
> caused
> >> in part by the API changes to deprecate APIs (and provide long-term
> >> replacements) and in part caused by 4079 [3], the real bug that we are
> >> trying to solve in 1.25.
> >>>
> >>> So, it is important that we release 1.25 soon, and that it solves all
> of
> >> these problems. I don’t know whether people will perceive 1.24 as a
> release
> >> “lower than our usual quality” (even though there are good reasons for
> it)
> >> but 1.25 needs to be back to the usual quality.
> >>>
> >>> Julian
> >>>
> >>> [1] https://issues.apache.org/jira/browse/CALCITE-4117 <
> >> https://issues.apache.org/jira/browse/CALCITE-4117>
> >>>
> >>> [2] https://issues.apache.org/jira/browse/CALCITE-4136 <
> >> https://issues.apache.org/jira/browse/CALCITE-4136>
> >>>
> >>> [3] https://issues.apache.org/jira/browse/CALCITE-4079 <
> >> https://issues.apache.org/jira/browse/CALCITE-4079>
> >>
>
>


Re: [DISCUSS] Towards Calcite 1.25.0

2020-07-24 Thread Andrei Sereda
It should be me.

I swapped the 1.22 release with Danny Chen who was supposed to be release
manager for 1.25

On Fri, Jul 24, 2020 at 12:52 PM Haisheng Yuan  wrote:

> Do we have release manager for v1.25.0?
>
>
> On 2020/07/23 17:15:12, Julian Hyde  wrote:
> > The release vote for 1.24 RC0 just passed [1], and it will be released
> shortly.
> >
> > We planned that release 1.24 is a transitional release, and 1.25 will
> follow soon afterwards. 1.24 deprecates some APIs that we intend to remove
> in 1.25. We had to make the release so that people can see that the APIs
> are deprecated, and replace them with the new versions.
> >
> > During the release vote we ran into 4136 [2]. This is a real bug, caused
> in part by the API changes to deprecate APIs (and provide long-term
> replacements) and in part caused by 4079 [3], the real bug that we are
> trying to solve in 1.25.
> >
> > So, it is important that we release 1.25 soon, and that it solves all of
> these problems. I don’t know whether people will perceive 1.24 as a release
> “lower than our usual quality” (even though there are good reasons for it)
> but 1.25 needs to be back to the usual quality.
> >
> > Julian
> >
> > [1] https://issues.apache.org/jira/browse/CALCITE-4117 <
> https://issues.apache.org/jira/browse/CALCITE-4117>
> >
> > [2] https://issues.apache.org/jira/browse/CALCITE-4136 <
> https://issues.apache.org/jira/browse/CALCITE-4136>
> >
> > [3] https://issues.apache.org/jira/browse/CALCITE-4079 <
> https://issues.apache.org/jira/browse/CALCITE-4079>
>


Re: Calcite PR CI offten failed due to elasticsearch:test

2020-07-09 Thread Andrei Sereda
Hello,

I'll take a look at failing tests. It seems that embedded ES doesn't start
correctly.

Andrei.

On Thu, Jul 9, 2020 at 10:21 PM JiaTao Tao  wrote:

> another case
> https://travis-ci.org/github/apache/calcite/jobs/706573803
>
> FAILURE   0.0sec, org.apache.calcite.test.RelMetadataTest >
> testPullUpPredicatesFromUnion2()
> java.lang.AssertionError:
> Expected: "[=($0, 1), OR(AND(=($1, 2), =($2, 3)), =($1, 4))]"
>  but: was "[=($0, 1), OR(AND(=($2, 3), =($1, 2)), =($1, 4))]"
>
> Regards!
>
> Aron Tao
>
>
> JiaTao Tao  于2020年7月9日周四 下午2:46写道:
>
> > Hi Stamatis Zampetakis
> >
> > I agree with you, on my local test, it is never failing, seems only a PR
> > CI problem.
> > Do you have any idea about disabling the tests only in PR CI?
> >
> > Regards!
> >
> > Aron Tao
> >
> >
> > Stamatis Zampetakis  于2020年7月2日周四 下午5:05写道:
> >
> >> I didn't observe the problem on my local post so if it is only a CI
> >> problem
> >> then it would be nice if we could disable the tests only there.
> >>
> >> Best,
> >> Stamatis
> >>
> >> On Thu, Jul 2, 2020 at 5:58 AM JiaTao Tao  wrote:
> >>
> >> > Ok, thanks for your suggestion. I'll open a JIRA and track the status.
> >> >
> >> >
> >> > Regards!
> >> >
> >> > Aron Tao
> >> >
> >> >
> >> > Danny Chan  于2020年7月2日周四 上午11:37写道:
> >> >
> >> > > 2 and 3 doesn’t really solve the problem, I would choose 1, you
> should
> >> > log
> >> > > these tests in the issue in order to track the status ~
> >> > >
> >> > > Best,
> >> > > Danny Chan
> >> > > 在 2020年7月2日 +0800 AM11:15,JiaTao Tao ,写道:
> >> > > > Hi Danny
> >> > > >
> >> > > >
> >> > > > There is 4 failed ut, and the root cause is java.net
> >> > > .SocketTimeoutException:
> >> > > > 30,000 milliseconds timeout on connection http-outgoing-2 :
> >> > > >
> >> > > > elasticsearch.MatchTest > initializationError
> >> > > > elasticsearch.BooleanLogicTest > initializationError
> >> > > > elasticsearch.AggregationTest > initializationError
> >> > > > elasticsearch.ProjectionTest > initializationError
> >> > > >
> >> > > > Here come the 3 solutions, hope to hear your advice.
> >> > > > 1. Disable these UTs
> >> > > > 2. Increase the timeout
> >> > > > 3. Mark these UTs as slow tests
> >> > > >
> >> > > >
> >> > > > Regards!
> >> > > >
> >> > > > Aron Tao
> >> > > >
> >> > > >
> >> > > > Danny Chan  于2020年6月28日周日 上午10:01写道:
> >> > > >
> >> > > > > Yes, it times out often, can you log an issue there and disable
> >> the
> >> > > case ?
> >> > > > >
> >> > > > > Best,
> >> > > > > Danny Chan
> >> > > > > 在 2020年6月26日 +0800 PM6:00,JiaTao Tao ,写道:
> >> > > > > > Seems an unstable case.
> >> > > > > >
> >> > > > > >
> >> > > > > > Regards!
> >> > > > > >
> >> > > > > > Aron Tao
> >> > > > >
> >> > >
> >> >
> >>
> >
>


[jira] [Created] (CALCITE-3912) Incorrect mapping parsing when properties have same name as reserved keywords in ElasticSearch

2020-04-10 Thread Andrei Sereda (Jira)
Andrei Sereda created CALCITE-3912:
--

 Summary: Incorrect mapping parsing when properties have same name 
as reserved keywords in ElasticSearch
 Key: CALCITE-3912
 URL: https://issues.apache.org/jira/browse/CALCITE-3912
 Project: Calcite
  Issue Type: Improvement
  Components: elasticsearch-adapter
Reporter: Andrei Sereda
Assignee: Andrei Sereda


If a property has name {{type}} or {{properties}} ES adapter doesn't process 
them correctly



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [DISCUSS] Towards Calcite 1.22

2020-02-11 Thread Andrei Sereda
Thanks for stepping in Danny. Can I take your release ?

On Mon, Feb 10, 2020 at 2:34 PM Julian Hyde  wrote:

> It would be helpful for us to test third-party projects.
>
> But equally, it is useful for third-party projects to test against us.
> (Especially non-open-source ones, which we cannot test.) I strongly suggest
> that owners of those projects do a build and test against Calcite master
> about 3 weeks before a Calcite release. It gives us chance to address any
> regressions before the release.
>
> > In HerdDB we saw regressions too late and the code was no more compatible
> > with Calcite master so we are still using a very old version of Calcite.
>
> I’ve seen that pattern often. It happened in Drill too, and they had to
> make Herculean efforts to get back onto the latest release. It’s in no
> one’s interests for dependent projects to slip behind. If the projects
> raise issues in at the right time (about 2 weeks before a release) we
> should endeavor to fix them.
>
> Julian
>
>
>
> > On Feb 9, 2020, at 6:13 AM, Enrico Olivelli  wrote:
> >
> > Il Dom 9 Feb 2020, 08:41 Stamatis Zampetakis  ha
> scritto:
> >
> >> Thanks for fixing the build Vladimir!
> >>
> >> I like the idea of testing against other projects on a weekly basis. It
> >> will certainly help detect regressions early on. It might be a bit hard
> to
> >> maintain since there could be failures quite often but I guess we will
> not
> >> know till we try.
> >>
> >> Even before adding 3rd-party projects in the CI, I would say that is
> worth
> >> running our integration tests (Druid, Cassandra, Postgres, etc.)
> >
> >
> > +1
> >
> > I think that third party users should test their code against current
> > Calcite master and report to this list all problems as soon as possible.
> >
> > In HerdDB we saw regressions too late and the code was no more compatible
> > with Calcite master so we are still using a very old version of Calcite.
> >
> > We started to have a branch that builds and runs tests against Calcite
> > master.
> > Showstoppers in this process are when we break source/binary
> compatibility
> > in Calcite, so you have to maintain a separate branch, because you cannot
> > depend on SNAPSHOT release  and this is expected to happen at every
> release.
> >
> > Having more frequent releases in Calcite would help a bit, but currently
> it
> > is not a big burden
> >
> >
> > Enrico
> >
> > at a
> >> regular basis by CI. I am checking them now and there seems to be again
> >> failures.
> >>
> >> Best,
> >> Stamatis
> >>
> >>
> >>
> >> On Sat, Feb 8, 2020 at 11:48 AM Vladimir Sitnikov <
> >> sitnikov.vladi...@gmail.com> wrote:
> >>
>  Are current -SNAPSHOT packages on repository.apache.org up to date ?
> >>>
> >>> The snapshots were not up to date because Calcite-Snapshots Jenkins job
> >> was
> >>> using beam Jenkins node somehow.
> >>> I guess that was caused by misconfiguration of beam nodes.
> >>>
> >>> I've triggered the job manually, and it works now:
> >>> https://builds.apache.org/job/Calcite-Snapshots/
> >>> On top of that, I've configured mails to dev@calcite list for the
> >>> snapshots
> >>> job so we'll know if it fails again.
> >>>
>  I would like to test my projects in CI against current master
> >>>
> >>> I wonder if it makes sense to add GitHub Actions CI which would
> validate
> >>> third-party projects on a weekly basis.
> >>> For instance, I have https://github.com/vlsi/mat-calcite-plugin ,
> which
> >> is
> >>> not that sophisticated, however, it would be nice to see
> >>> if the upcoming Calcite version is going to break or not that client.
> >>>
> >>> For instance, Beam has quite interesting post-commit tests page:
> >>>
> https://github.com/apache/beam#post-commit-tests-status-on-master-branch
> >>>
> >>> WDYT?
> >>>
> >>> Vladimir
> >>>
> >>
>
>


Re: [DISCUSS] Towards Calcite 1.22

2020-02-07 Thread Andrei Sereda
Is there anyone willing to swap a Calcite release with me ?

On Fri, Feb 7, 2020 at 12:41 PM Andrei Sereda  wrote:

> Hi Julian et al,
>
> Unfortunately my current work schedule is still very tense. There are some
> internal deadlines that have passed already.
>
> I would appreciate if I can exchange 1.22 Calcite release with a Release
> Manager of a later version (perhaps 1.23 or 1.24?)
>
> Again, apologies to all for this situation as I didn't expect this
> quarter to be the way it turned out.
>
> Andrei.
>
>
>
>
> On Thu, Feb 6, 2020 at 7:21 PM Julian Hyde  wrote:
>
>> Andrei,
>>
>> Do you know when you might be available? Two weeks have passed since
>> your last note.
>>
>> We originally wanted to release in December, then it was pushed back
>> to mid-January. We can't wait much longer.
>>
>> Julian
>>
>> On Wed, Jan 22, 2020 at 8:07 AM Andrei Sereda  wrote:
>> >
>> > Hello,
>> >
>> > I would like to ask community if it is OK if 1.22 release gets delayed
>> by
>> > 2-3 weeks ?
>> >
>> > I have tried to book 1 week from work but, unfortunately, right now it
>> is
>> > not easy (things should be better in February).
>> >
>> > Another option is to swap with somebody doing next (1.2[345]) release.
>> >
>> > Please let me know what you think and apologies for the inconvenience.
>> >
>> > Andrei.
>> >
>> >
>> > On Wed, Dec 4, 2019 at 4:55 PM Julian Hyde  wrote:
>> >
>> > > I don’t mind whether the release happens in December or January, but
>> > > either way, let’s start burning down the backlog of PRs now.
>> > >
>> > >
>> > > > On Dec 2, 2019, at 11:43 PM, Enrico Olivelli 
>> > > wrote:
>> > > >
>> > > > Andrei
>> > > >
>> > > > Il mar 3 dic 2019, 08:21 Rui Wang > > > amaliu...@apache.org>> ha scritto:
>> > > >
>> > > >> Thank you for this notification.
>> > > >>
>> > > >> Please try to make CALCITE-3272[1] into 1.22 (change the fix
>> version to
>> > > >> 1.22 already).
>> > > >>
>> > > >>
>> > > >> [1]: https://github.com/apache/calcite/pull/1587
>> > > >>
>> > > >> -Rui
>> > > >>
>> > > >> On Mon, Dec 2, 2019 at 6:35 PM Chunwei Lei > >
>> > > wrote:
>> > > >>
>> > > >>> Thank you for your work, Anderi.
>> > > >>>
>> > > >>> Let's get CALCITE-1581[1] into 1.22.
>> > > >>>
>> > > >>> +1 for release at early-mid January '20 (to have more time to
>> review
>> > > >> prs).
>> > > >>>
>> > > >>>
>> > > >>> [1] https://github.com/apache/calcite/pull/1138
>> > > >>>
>> > > >>>
>> > > >>> Best,
>> > > >>> Chunwei
>> > > >>>
>> > > >>>
>> > > >>> On Tue, Dec 3, 2019 at 8:02 AM Andrei Sereda 
>> wrote:
>> > > >>>
>> > > >>>> Hello,
>> > > >>>>
>> > > >>>> Calcite 1.21 was released about 3 months ago (2019-09) and it is
>> time
>> > > >> to
>> > > >>>> start preparation for 1.22.
>> > > >>>>
>> > > >>>> Current open issues and pull requests can be seen in [1] and [2].
>> > > There
>> > > >>> are
>> > > >>>> many PRs left from previous releases and it would be nice to
>> review as
>> > > >>> many
>> > > >>>> as possible. Please change "fix version" in JIRA to 1.22 if you
>> would
>> > > >>> like
>> > > >>>> the contribution be considered for this release. It is also
>> helpful to
>> > > >>> mark
>> > > >>>> PR with "LGTM-will-merge-soon" label so other contributors are
>> aware
>> > > of
>> > > >>>> your review.
>> > > >>>>
>> > > >>>> Committers please go over existing PRs and try to prioritize /
>> > > finalize
>> > > >>>> them. Also let me know which changes (in your opinion) are ready
>> or
>> > > >>> should
>> > > >>>> be considered for this release. Don't forget that current policy
>> of
>> > > >>>> frequent releases allows better work scheduling without blocking
>> > > >> existing
>> > > >>>> release plan.
>> > > >>>>
>> > > >>>> In terms of dates, let's agree on release time frame late
>> December '19
>> > > >> or
>> > > >>>> early-mid January '20 ?
>> > > >>
>> > > >
>> > > > I (from HerdDB community) would prefer late December if possible,
>> as we
>> > > are
>> > > > stuck to an older 1.19 version of Calcite.
>> > > > Current Calcite master is is great shape from our point of view
>> > > >
>> > > > Thanks for driving this
>> > > > Enrico
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >>>
>> > > >>>> Let me know if I have missed anything or if current plan is
>> > > >> inconvenient.
>> > > >>>>
>> > > >>>> Thanks,
>> > > >>>> Andrei.
>> > > >>>>
>> > > >>>> [1]
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>> > > <
>> > >
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>> > > >
>> > > >>>> [2] https://github.com/apache/calcite/pulls <
>> > > https://github.com/apache/calcite/pulls>
>> > >
>>
>


Re: [DISCUSS] Towards Calcite 1.22

2020-02-07 Thread Andrei Sereda
Hi Julian et al,

Unfortunately my current work schedule is still very tense. There are some
internal deadlines that have passed already.

I would appreciate if I can exchange 1.22 Calcite release with a Release
Manager of a later version (perhaps 1.23 or 1.24?)

Again, apologies to all for this situation as I didn't expect this
quarter to be the way it turned out.

Andrei.




On Thu, Feb 6, 2020 at 7:21 PM Julian Hyde  wrote:

> Andrei,
>
> Do you know when you might be available? Two weeks have passed since
> your last note.
>
> We originally wanted to release in December, then it was pushed back
> to mid-January. We can't wait much longer.
>
> Julian
>
> On Wed, Jan 22, 2020 at 8:07 AM Andrei Sereda  wrote:
> >
> > Hello,
> >
> > I would like to ask community if it is OK if 1.22 release gets delayed by
> > 2-3 weeks ?
> >
> > I have tried to book 1 week from work but, unfortunately, right now it is
> > not easy (things should be better in February).
> >
> > Another option is to swap with somebody doing next (1.2[345]) release.
> >
> > Please let me know what you think and apologies for the inconvenience.
> >
> > Andrei.
> >
> >
> > On Wed, Dec 4, 2019 at 4:55 PM Julian Hyde  wrote:
> >
> > > I don’t mind whether the release happens in December or January, but
> > > either way, let’s start burning down the backlog of PRs now.
> > >
> > >
> > > > On Dec 2, 2019, at 11:43 PM, Enrico Olivelli 
> > > wrote:
> > > >
> > > > Andrei
> > > >
> > > > Il mar 3 dic 2019, 08:21 Rui Wang  > > amaliu...@apache.org>> ha scritto:
> > > >
> > > >> Thank you for this notification.
> > > >>
> > > >> Please try to make CALCITE-3272[1] into 1.22 (change the fix
> version to
> > > >> 1.22 already).
> > > >>
> > > >>
> > > >> [1]: https://github.com/apache/calcite/pull/1587
> > > >>
> > > >> -Rui
> > > >>
> > > >> On Mon, Dec 2, 2019 at 6:35 PM Chunwei Lei 
> > > wrote:
> > > >>
> > > >>> Thank you for your work, Anderi.
> > > >>>
> > > >>> Let's get CALCITE-1581[1] into 1.22.
> > > >>>
> > > >>> +1 for release at early-mid January '20 (to have more time to
> review
> > > >> prs).
> > > >>>
> > > >>>
> > > >>> [1] https://github.com/apache/calcite/pull/1138
> > > >>>
> > > >>>
> > > >>> Best,
> > > >>> Chunwei
> > > >>>
> > > >>>
> > > >>> On Tue, Dec 3, 2019 at 8:02 AM Andrei Sereda 
> wrote:
> > > >>>
> > > >>>> Hello,
> > > >>>>
> > > >>>> Calcite 1.21 was released about 3 months ago (2019-09) and it is
> time
> > > >> to
> > > >>>> start preparation for 1.22.
> > > >>>>
> > > >>>> Current open issues and pull requests can be seen in [1] and [2].
> > > There
> > > >>> are
> > > >>>> many PRs left from previous releases and it would be nice to
> review as
> > > >>> many
> > > >>>> as possible. Please change "fix version" in JIRA to 1.22 if you
> would
> > > >>> like
> > > >>>> the contribution be considered for this release. It is also
> helpful to
> > > >>> mark
> > > >>>> PR with "LGTM-will-merge-soon" label so other contributors are
> aware
> > > of
> > > >>>> your review.
> > > >>>>
> > > >>>> Committers please go over existing PRs and try to prioritize /
> > > finalize
> > > >>>> them. Also let me know which changes (in your opinion) are ready
> or
> > > >>> should
> > > >>>> be considered for this release. Don't forget that current policy
> of
> > > >>>> frequent releases allows better work scheduling without blocking
> > > >> existing
> > > >>>> release plan.
> > > >>>>
> > > >>>> In terms of dates, let's agree on release time frame late
> December '19
> > > >> or
> > > >>>> early-mid January '20 ?
> > > >>
> > > >
> > > > I (from HerdDB community) would prefer late December if possible, as
> we
> > > are
> > > > stuck to an older 1.19 version of Calcite.
> > > > Current Calcite master is is great shape from our point of view
> > > >
> > > > Thanks for driving this
> > > > Enrico
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >>>
> > > >>>> Let me know if I have missed anything or if current plan is
> > > >> inconvenient.
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Andrei.
> > > >>>>
> > > >>>> [1]
> > > >>>>
> > > >>>
> > > >>
> > >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > <
> > >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > >
> > > >>>> [2] https://github.com/apache/calcite/pulls <
> > > https://github.com/apache/calcite/pulls>
> > >
>


Re: [DISCUSS] Towards Calcite 1.22

2020-01-22 Thread Andrei Sereda
Hello,

I would like to ask community if it is OK if 1.22 release gets delayed by
2-3 weeks ?

I have tried to book 1 week from work but, unfortunately, right now it is
not easy (things should be better in February).

Another option is to swap with somebody doing next (1.2[345]) release.

Please let me know what you think and apologies for the inconvenience.

Andrei.


On Wed, Dec 4, 2019 at 4:55 PM Julian Hyde  wrote:

> I don’t mind whether the release happens in December or January, but
> either way, let’s start burning down the backlog of PRs now.
>
>
> > On Dec 2, 2019, at 11:43 PM, Enrico Olivelli 
> wrote:
> >
> > Andrei
> >
> > Il mar 3 dic 2019, 08:21 Rui Wang  amaliu...@apache.org>> ha scritto:
> >
> >> Thank you for this notification.
> >>
> >> Please try to make CALCITE-3272[1] into 1.22 (change the fix version to
> >> 1.22 already).
> >>
> >>
> >> [1]: https://github.com/apache/calcite/pull/1587
> >>
> >> -Rui
> >>
> >> On Mon, Dec 2, 2019 at 6:35 PM Chunwei Lei 
> wrote:
> >>
> >>> Thank you for your work, Anderi.
> >>>
> >>> Let's get CALCITE-1581[1] into 1.22.
> >>>
> >>> +1 for release at early-mid January '20 (to have more time to review
> >> prs).
> >>>
> >>>
> >>> [1] https://github.com/apache/calcite/pull/1138
> >>>
> >>>
> >>> Best,
> >>> Chunwei
> >>>
> >>>
> >>> On Tue, Dec 3, 2019 at 8:02 AM Andrei Sereda  wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> Calcite 1.21 was released about 3 months ago (2019-09) and it is time
> >> to
> >>>> start preparation for 1.22.
> >>>>
> >>>> Current open issues and pull requests can be seen in [1] and [2].
> There
> >>> are
> >>>> many PRs left from previous releases and it would be nice to review as
> >>> many
> >>>> as possible. Please change "fix version" in JIRA to 1.22 if you would
> >>> like
> >>>> the contribution be considered for this release. It is also helpful to
> >>> mark
> >>>> PR with "LGTM-will-merge-soon" label so other contributors are aware
> of
> >>>> your review.
> >>>>
> >>>> Committers please go over existing PRs and try to prioritize /
> finalize
> >>>> them. Also let me know which changes (in your opinion) are ready or
> >>> should
> >>>> be considered for this release. Don't forget that current policy of
> >>>> frequent releases allows better work scheduling without blocking
> >> existing
> >>>> release plan.
> >>>>
> >>>> In terms of dates, let's agree on release time frame late December '19
> >> or
> >>>> early-mid January '20 ?
> >>
> >
> > I (from HerdDB community) would prefer late December if possible, as we
> are
> > stuck to an older 1.19 version of Calcite.
> > Current Calcite master is is great shape from our point of view
> >
> > Thanks for driving this
> > Enrico
> >
> >
> >
> >
> >
> >>>
> >>>> Let me know if I have missed anything or if current plan is
> >> inconvenient.
> >>>>
> >>>> Thanks,
> >>>> Andrei.
> >>>>
> >>>> [1]
> >>>>
> >>>
> >>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> <
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> >
> >>>> [2] https://github.com/apache/calcite/pulls <
> https://github.com/apache/calcite/pulls>
>


Re: Usage of SqlStdOperatorTable.BETWEEN from RelBuilder

2020-01-18 Thread Andrei Sereda
Hi Hrudaya,

It seems that SqlBetweenOperator doesn’t correctly infer return type when
created by RexBuilder.

As a workaround, can you replace BETWEEN by composition of two ANDs ? (user_id
>= 1 AND user_id <= 5)

// RelBuilder builder = ...
builder.scan("users");

RexNode condition1 = builder.call(SqlStdOperatorTable.GREATER_THAN_OR_EQUAL,
builder.field("user_id"),
builder.literal(20));

RexNode condition2 = builder.call(SqlStdOperatorTable.LESS_THAN_OR_EQUAL,
builder.field("user_id"),
builder.literal(30));
RexNode between = builder.and(condition1, condition2);

RelNode root = builder
.filter(between)
.build();

Devs,

Do you agree to set returnTypeInference to ReturnTypes.BOOLEAN_NULLABLE (in
constructor) for SqlBetweenOperator ? And handle the case with
RexCallBinding ?

Thanks,
Andrei.

On Fri, Jan 17, 2020 at 8:56 PM Hrudaya Reddy  wrote:

> Hi all,
>
> We are trying to generate the following sql query
>
> SELECT [user_id], [create_date]
> FROM [users]
> WHERE [user_id] BETWEEN 1 AND 5
>
> I am trying the following but I get ClassCastException error
>
> RexNode betweenCondition = relBuilder.call(SqlStdOperatorTable.BETWEEN,
> relBuilder.field("user_id"),
>  relBuilder.literal(1), relBuilder.literal(5));
>
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.calcite.rex.RexCallBinding cannot be cast to
> org.apache.calcite.sql.SqlCallBinding
> at
> org.apache.calcite.sql.fun.SqlBetweenOperator.inferReturnType(SqlBetweenOperator.java:139)
> at
> org.apache.calcite.rex.RexBuilder.deriveReturnType(RexBuilder.java:276)
> at org.apache.calcite.tools.RelBuilder.call(RelBuilder.java:602)
> at org.apache.calcite.tools.RelBuilder.call(RelBuilder.java:596)
>
> I would really appreciate it if you could guide me with the correct usage
> of the BETWEEN operator.
>
> Thanks in advance.
>
> Regards,
> Hrudaya
>
> This message, together with any attachments, is intended only for the use
> of the individual or entity to which it is addressed and may contain
> confidential and/or privileged information. If you are not the intended
> recipient(s), or the employee or agent responsible for delivery of this
> message to the intended recipient(s), you are hereby notified that any
> dissemination, distribution or copying of this message, or any attachment,
> is strictly prohibited. If you have received this message in error, please
> immediately notify the sender and delete the message, together with any
> attachments, from your computer. Thank you for your cooperation.
>


Re: Calcite Adapter Question

2020-01-17 Thread Andrei Sereda
Hi Charles,

There is some documentation here
https://calcite.apache.org/docs/adapter.html it describes how to setup and
use an adapter.

Note that you can only use those adapters within calcite runtime and not as
a standalone library.

Typical adapter would expose collection (for Mongo), index (for ES), region
(for Geode) etc.  as a calcite schema / table which you can query using
relational algebra.

How exactly do you want to extend existing adapters ?

Hope that helps.

Regards,
Andrei.




On Fri, Jan 17, 2020 at 1:29 PM Charles Givre  wrote:

> Hello Calcite Devs!
> My name is Charles Givre and I'm the PMC Chair for Apache Drill, which
> uses Calcite for query planning among other things.  I'm working on
> extending the number of systems that Drill can connect to and I saw that
> Calcite has a number of adapters for various systems like Cassandra and
> Elasticsearch.
>
> Could anyone point me to some resources as to how these adapters can be
> used (or extended) so that Drill could use them?
> Thank you very much!
> -- C


Re: Draft board report for January 2020

2020-01-02 Thread Andrei Sereda
+1

Question regarding Hazelcast :

> Finally, the Hazelcast system has decided to adopt Calcite for query
planning.

Was it Ignite [1] or Hazelcast team to adopt (prototype) Calcite ?

https://lists.apache.org/thread.html/4211dbbe35690e70462370886afcbb35419ff016b0ee604acf07a4d3%40%3Cdev.ignite.apache.org%3E
 [1]

On Thu, Jan 2, 2020 at 3:42 PM Rui Wang  wrote:

> Looks nice! Thank you Stamatis!
>
>
>
> -Rui
>
>
>
> On Wed, Jan 1, 2020 at 6:52 PM Matt Wang  wrote:
>
> > +1, looks good. Thanks~
> >
> >
> > ---
> > Best,
> > Matt Wang
> >
> >
> > On 01/2/2020 09:57,Chunwei Lei wrote:
> > +1, looks good.
> > Thanks, Stamatis~~
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Thu, Jan 2, 2020 at 8:41 AM Haisheng Yuan 
> > wrote:
> >
> > +1, looks good to me.
> > Thanks.
> >
> > - Haisheng
> >
> > --
> > 发件人:Francis Chuang
> > 日 期:2020年01月02日 04:54:46
> > 收件人:
> > 主 题:Re: Draft board report for January 2020
> >
> > +1, looks good, Stamatis!
> >
> > On 1/01/2020 9:18 pm, Stamatis Zampetakis wrote:
> > Attached below is a draft of this month's board report. I plan to submit
> > it
> > on January 7. Please let me know if you have any additions or
> > corrections.
> >
> > ## Description:
> > Apache Calcite is a highly customizable framework for parsing and
> > planning
> > queries on data in a wide variety of formats. It allows database-like
> > access,
> > and in particular a SQL interface and advanced query optimization, for
> > data
> > not
> > residing in a traditional database.
> >
> > Avatica is a sub-project within Calcite and provides a framework for
> > building
> > local and remote JDBC and ODBC database drivers. Avatica has an
> > independent
> > release schedule and its own repository.
> >
> > ## Issues:
> > There are no issues requiring board attention.
> >
> > ## Membership Data:
> > Apache Calcite was founded 2015-10-22 (4 years ago).
> > There are currently 45 committers and 22 PMC members in this project.
> > The Committer-to-PMC ratio is roughly 2:1.
> >
> > Community changes, past quarter:
> > - Danny Chen was added to the PMC on 2019-10-30.
> > - Haisheng Yuan was added to the PMC on 2019-11-11.
> > - Stamatis Zampetakis was appointed as PMC chair on 2019-12-18,
> > continuing the tradition of the project of rotating the chair every year.
> > - No new committers. Last addition was Mohamed Mohsen on 2019-09-17.
> >
> > ## Project Activity:
> > Calcite 1.21.0 was released in the middle of September, including more
> > than
> > 100
> > resolved issues and maintaining a release cadence of roughly one release
> > per
> > quarter.
> >
> > Calcite 1.22.0 is under preparation and is expected to be released inside
> > January while at the moment contains more than 230 commits and 150
> > resolved
> > issues.
> >
> > Avatica 1.16.0 was released in the middle of December, including numerous
> > bug
> > fixes and security improvements while the build system has been migrated
> > from
> > maven to gradle.
> >
> > The build and test infrastructure has been modernized for both Calcite
> > and
> > Avatica, with the migration from maven to gradle, JUnit4 to JUnit5, and
> > the
> > introduction of GitHub actions as part of the CI. The changes shall
> > improve
> > developers experience, code quality, and protect better against
> > regressions.
> >
> > Members of the project participated in ApacheCon EU on October and Flink
> > Forward
> > Asia on November, representing the community, and presenting talks about
> > Calcite.
> >
> > Finally, the Hazelcast system has decided to adopt Calcite for query
> > planning.
> >
> > ## Community Health:
> >
> > Activity levels on mailing lists (37%), git (40%) and JIRA (opened 15%,
> > closed
> > 19%) have increased significantly in the last quarter. One reason is the
> > modernization of the build and test infrastructure for both Calcite and
> > Avatica,
> > which triggered  many discussions and follow-up tasks. Another reason, is
> > the
> > changes in the roster of the PMC and open discussions about the future of
> > the
> > project. Last but not least, is the involvement of new people in the
> > community
> > bringing up new challenges and ideas for improvements.
> >
> > The rates of pull requests being closed and merged on Github has
> > increased
> > by
> > 16%, as we work to clear our backlog. Nevertheless, the number of open
> > pull
> > requests is still big since the number of committers who get involved in
> > reviews
> > is rather small. Furthermore, there are pull requests which are stale,
> > work in progress, or proposals that make the numbers look even bigger. On
> > the
> > positive side every pull request receives comments within a couple of
> > days
> > after
> > being submitted and there are many which get merged without too much
> > effort
> > showing that the project attracts skilled developers who may turn into
> > committers quite soon.
> >
> >
> >
>


Re: CsvAdapter (Json content) from String / InputStream

2019-12-05 Thread Andrei Sereda
Pls see CALCITE-3560 [1] which was merged recently. You can now instantiate
Source from a generic CharSource [2]:

Source source = Sources.fromCharSource(CharSource.wrap("hello"));

This should be released with 1.22

[1] https://issues.apache.org/jira/browse/CALCITE-3560
<https://issues.apache.org/jira/browse/CALCITE-3560#>
[2]
https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html

On Tue, Nov 19, 2019 at 1:07 PM Yanna elina 
wrote:

> Hi guys ,
>
> i have another question about this adapter.
> I have a json sample like this :
> [
>   {
> "field": "test",
> "properties": [
>   "a",
>   "b",
>   "c"
> ]
>   }
> ]
>
> JsonTable  look like to convert Array to  OTHER  ColumType .
> the column  "properties" is converted on  ' JAVA.UTIL.ARRAYLIST)>
>  when i check JsonEnumerator  i can see this function code :*RelDataType
> type = typeFactory.createJavaType(jsonFieldMap.get(key).getClass());*
>
> *About WHERE  / INis it supposed to work? on JavaType(ArrayList) ? *
> if i try to make this query "SELECT * FROM TABLE_A WHERE
> properties=any('a') i will have alway an Exception
> : org.apache.calcite.sql.validate.SqlValidatorException: Values passed to
> IN operator must have compatible type
>
> *if its not supposed to work i guess i need to re-implement this one to
> convert *JAVA.UTIL.ARRAYLIST on SQL_ARRAY type right ?
>
> thank
>
>
>
> Le lun. 18 nov. 2019 à 19:15, Yanna elina  a
> écrit :
>
> > Big Thank Guys  !!!
> >
> > Even if this CSVAdapter is an "example" its still really usefull  :)  and
> > with this update it will be a good "out of box" tools usable in many
> > scenario/workflow
> >
> >
> > Yanna
> >
> > Le jeu. 14 nov. 2019 à 21:20, Andrei Sereda  a écrit :
> >
> >> > I see that this feature request relates to Source.java and
> Sources.java,
> >> which are in org.apache.calcite.util in core.
> >> I'm not planning to change Source.java it already exposes Reader /
> >> InputStream
> >>
> >> > If you add some capability, it is fine to add It to the CSV adapter
> >> example, but it is much more important that that capability exists in
> the
> >> file adapter.
> >> I will add to both. The general idea behind this change is that
> currently
> >> CSV / File Adapter(s) require inputs to be File(s) or URL(s) which
> forces
> >> users to create temporal resources manually (when their content is
> already
> >> in-memory). If input to CSV / File adapter(s) is generic Readable [1] /
> >> Reader [2] or InputStream it gives more flexibility to users.
> >>
> >> [1] https://docs.oracle.com/javase/7/docs/api/java/lang/Readable.html
> >> [2] https://docs.oracle.com/javase/7/docs/api/java/io/Reader.html
> >>
> >>
> >> On Thu, Nov 14, 2019 at 2:45 PM Julian Hyde  wrote:
> >>
> >> > I see that this feature request relates to Source.java and
> Sources.java,
> >> > which are in org.apache.calcite.util in core.
> >> >
> >> > If you add some capability, it is fine to add It to the CSV adapter
> >> > example, but it is much more important that that capability exists in
> >> the
> >> > file adapter.
> >> >
> >> > Julian
> >> >
> >> >
> >> > > On Nov 14, 2019, at 11:36 AM, Andrei Sereda 
> wrote:
> >> > >
> >> > > I think the change is straightforward (will not add complexity).
> >> > >
> >> > > On Thu, Nov 14, 2019 at 1:24 PM Julian Hyde 
> wrote:
> >> > >
> >> > >> Remember that CsvAdapter is in the “example” module. Keep it
> simple.
> >> > >>
> >> > >> The file adapter can also parse CSV files.
> >> > >>
> >> > >> Julian
> >> > >>
> >> > >>
> >> > >>
> >> > >>> On Nov 14, 2019, at 9:40 AM, Andrei Sereda 
> >> wrote:
> >> > >>>
> >> > >>> Hello,
> >> > >>>
> >> > >>> Source object already exposes Reader / InputStream API. Probably
> >> > >>> JsonEnumerator can be changed to use those methods.
> >> > >>>
> >> > >>> Do you mind creating a JIRA ticket ? I'll take a look.
> >> > >>>
> >> > >>> Thanks,
> >> > >>> Andrei.
> >> > >>>
> >> > >>> On Thu, Nov 14, 2019 at 7:45 AM Yanna elina <
> >> > yannaelinasul...@gmail.com>
> >> > >>> wrote:
> >> > >>>
> >> > >>>> Hi guys ,
> >> > >>>> I saw in the code that this nice adapter makes it possible to
> make
> >> SQL
> >> > >>>> queries on the data JSON
> >> > >>>>
> >> > >>>>
> >> > >>
> >> >
> >>
> https://github.com/apache/calcite/tree/ab71c4cae5a5c3c7d979337a2d38ddaf271aa206/example/csv/src/main/java/org/apache/calcite/adapter/csv
> >> > >>>>
> >> > >>>> But  it's limited on File / URL.
> >> > >>>> JsonTable constructor accepte only a Source object and this
> Source
> >> > >> object
> >> > >>>> can be construct only accross  a File / URL.
> >> > >>>>
> >> > >>>> it could be nice to have the possibility to make this source from
> >> > >>>> ImputStream too .
> >> > >>>>
> >> > >>>> Creating a temp-file from an InputStream or String can be
> excesive.
> >> > >>>>
> >> > >>>> Thanks
> >> > >>>>
> >> > >>
> >> > >>
> >> >
> >> >
> >>
> >
>


[jira] [Created] (CALCITE-3560) Allow generic data source (eg. InputStream) in CSVAdapter or FileAdapter(s)

2019-12-03 Thread Andrei Sereda (Jira)
Andrei Sereda created CALCITE-3560:
--

 Summary: Allow generic data source (eg. InputStream) in CSVAdapter 
or FileAdapter(s)
 Key: CALCITE-3560
 URL: https://issues.apache.org/jira/browse/CALCITE-3560
 Project: Calcite
  Issue Type: Improvement
  Components: csv-adapter, file-adapter
Affects Versions: 1.21.0
Reporter: Andrei Sereda
Assignee: Andrei Sereda


Currently CSV Adapter requires data to be stored on disk or remotely because 
table constructor argument is 
[URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. 

Change CSV and File adapter to accept more generic source like 
[Readable|https://docs.oracle.com/javase/8/docs/api/java/lang/Readable.html] or 
[InputStream|https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html]
 so adapters can operate on in-memory elements like String. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: JUnit 4 and JUnit 5 annotations do not mix well

2019-12-03 Thread Andrei Sereda
Thanks Vladimir. Most of the changes look find to me (left a small comment
in PR)

Once merged, I'll take care of remaining JUnit4 rules for
Cassandra/ElasticSearch/Mongo etc.


On Tue, Dec 3, 2019 at 1:23 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Ok, I think PR1621 is ready to go:
> https://github.com/apache/calcite/pull/1621
> I'm inclined to merge it shortly
>
> The PR converts most of the tests, and by default, it allows JUnit5 only.
>
> Certain modules still have "non-trivial" JUnit4 code, and there was an
> agreement to convert them later.
> The modules receive junit4 dependency via junit4=true in gradle.properties.
>
> ---
>
> The most "controversial" change from my point of view is the removal of
> *Suite* classes.
> In other words, I have dropped classes like
> CalciteSuite, FileSuite, PlusSuite, and so on.
>
> I guess it is OK, as both Gradle and JUnit5 provide lots of ways to launch
> tests (e.g. tags are good).
> The good thing about the removal is it would reduce the number of
> merge-conflicts,
> and it would simplify adding new test classes.
>
> ---
>
> The most notable difference between junit4 and junit5 .assert* is that
> junit4 has (message, expected, actual)
> argument order while junit5 uses (expected, actual, message).
> The latter is better when message is big (e.g. concatenated), and junit5
> allows to use lambda,
> so the message is built only when assertion fails.
>
> I've performed argument shuffling with IntelliJ IDEA's "structural search
> and replace", so it should be OK.
>
> Vladimir
>


[DISCUSS] Towards Calcite 1.22

2019-12-02 Thread Andrei Sereda
Hello,

Calcite 1.21 was released about 3 months ago (2019-09) and it is time to
start preparation for 1.22.

Current open issues and pull requests can be seen in [1] and [2]. There are
many PRs left from previous releases and it would be nice to review as many
as possible. Please change "fix version" in JIRA to 1.22 if you would like
the contribution be considered for this release. It is also helpful to mark
PR with "LGTM-will-merge-soon" label so other contributors are aware of
your review.

Committers please go over existing PRs and try to prioritize / finalize
them. Also let me know which changes (in your opinion) are ready or should
be considered for this release. Don't forget that current policy of
frequent releases allows better work scheduling without blocking existing
release plan.

In terms of dates, let's agree on release time frame late December '19 or
early-mid January '20 ?

Let me know if I have missed anything or if current plan is inconvenient.

Thanks,
Andrei.

[1]
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
[2] https://github.com/apache/calcite/pulls


Re: JUnit 4 and JUnit 5 annotations do not mix well

2019-12-02 Thread Andrei Sereda
I also lean towards updating existing tests to JUnit5. Perhaps split it
into two parts:

1. The ones that can be migrated easily (replacing annotations, minimal
manual intervention)
2. Existing JUnit 4 rules / parameterized tests

JUnit4 and JUnit5 can coexists and evaluated by the same engine.

On Mon, Dec 2, 2019 at 5:19 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Stamatis> If we go for the bulk modifications approach why not migrating
> completely to JUnit5?
>
> Migration to JUnit5 seems to be ok.
>
> I've filed a draft that updates the APIs:
> https://github.com/apache/calcite/pull/1621
> It does not seem to touch too many places, and in most of the cases, it is
> a mere import adjustment.
>
> Vladimir
>


Re: JUnit 4 and JUnit 5 annotations do not mix well

2019-12-02 Thread Andrei Sereda
> If we go for the bulk modifications approach why not migrating completely
to JUnit5?

Most of the tests can be migrated programmatically (string/replace) there
are some which need to be done manually (eg. JUnit special rules like
EmbeddedElasticsearchPolicy [1] and parameterized tests ).

> I remember that we had a discussion around the subject before but I
cannot find the thread at the moment.
See [2]  for relevant thread.

There were several concerns (at the time) :

1. Noise in commit history
2. Require use of newer versions of build tools (maven, IDE etc.)
3. Support of parallel execution of tests (from maven / gradle). Now
supported in 5.5

I'm happy to revive CALCITE-2457 if people are interested

https://github.com/apache/calcite/blob/ab136b5f76a4cb951e847fcba6b414c5e80dbbe6/elasticsearch/src/test/java/org/apache/calcite/adapter/elasticsearch/EmbeddedElasticsearchPolicy.java
 [1]
https://lists.apache.org/thread.html/3c2e87359442eefbce67823926d3701e2541df1c798025be4a31e779@%3Cdev.calcite.apache.org%3E
 [2]



On Mon, Dec 2, 2019 at 2:16 PM Stamatis Zampetakis 
wrote:

> If we go for the bulk modifications approach why not migrating completely
> to JUnit5?
>
> I remember that we had a discussion around the subject before but I cannot
> find the thread at the moment.
>
>
> On Mon, Dec 2, 2019, 5:58 PM Andrei Sereda  wrote:
>
> > Do you think it makes sense to perform a bulk string/replace for JUnit 4
> ->
> > 5 annotations ? At least for simple non-parameterized / no-rules tests.
> > This way IDE will automatically select correct annotations.
> >
> > I had some scripts prepared as part of CALCITE-2457 [1]
> >
> > https://issues.apache.org/jira/browse/CALCITE-2457 [1]
> >
> > On Mon, Dec 2, 2019 at 8:13 AM Michael Mior  wrote:
> >
> > > Thanks for noting Stamatis!
> > >
> > > If a particular group of tests is migrating to JUnit 5, it also
> > > probably makes sense to use org.junit.jupiter.api.Assertions instead
> > > of org.junit.Assert. Although the latter is still supported, I think
> > > it makes sense to use things in the jupiter namespace where possible.
> > >
> > > --
> > > Michael Mior
> > > mm...@apache.org
> > >
> > >
> > > Le lun. 2 déc. 2019 à 07:53, Stamatis Zampetakis  a
> > > écrit :
> > > >
> > > > Hello,
> > > >
> > > > At the moment, we can use both JUnit 4 and 5 annotations in our code
> > > base.
> > > > Lately, I spend some time on debugging a few test cases only to
> realize
> > > > that old and new APIs do not mix very well. If you encounter problems
> > > with
> > > > your annotations then consider checking your imports. The problem
> might
> > > lie
> > > > on the fact that you are using at the same time annotations from
> > > different
> > > > versions.
> > > >
> > > > Consider for example the following test.
> > > >
> > > > import org.junit.Assert;
> > > > import org.junit.Test;
> > > > import org.junit.jupiter.api.Disabled;
> > > >
> > > > public class SimpleTest {
> > > >
> > > >   @Test
> > > >   @Disabled
> > > >   public void test() {
> > > > Assert.fail("Should not run because it is disabled");
> > > >   }
> > > > }
> > > >
> > > > Contrary to what people might expect the test above will run and will
> > > fail
> > > > with an assertion error. Changing the imports (see below) will make
> the
> > > > test behave as expected.
> > > >
> > > > package org.apache.calcite;
> > > >
> > > > import org.junit.Assert;
> > > > import org.junit.jupiter.api.Test;
> > > > import org.junit.jupiter.api.Disabled;
> > > >
> > > > public class SimpleTest {
> > > >
> > > >   @Test
> > > >   @Disabled
> > > >   public void test() {
> > > > Assert.fail("Should not run because it is disabled");
> > > >   }
> > > > }
> > > >
> > > > Best,
> > > > Stamatis
> > >
> >
>


Re: JUnit 4 and JUnit 5 annotations do not mix well

2019-12-02 Thread Andrei Sereda
Do you think it makes sense to perform a bulk string/replace for JUnit 4 ->
5 annotations ? At least for simple non-parameterized / no-rules tests.
This way IDE will automatically select correct annotations.

I had some scripts prepared as part of CALCITE-2457 [1]

https://issues.apache.org/jira/browse/CALCITE-2457 [1]

On Mon, Dec 2, 2019 at 8:13 AM Michael Mior  wrote:

> Thanks for noting Stamatis!
>
> If a particular group of tests is migrating to JUnit 5, it also
> probably makes sense to use org.junit.jupiter.api.Assertions instead
> of org.junit.Assert. Although the latter is still supported, I think
> it makes sense to use things in the jupiter namespace where possible.
>
> --
> Michael Mior
> mm...@apache.org
>
>
> Le lun. 2 déc. 2019 à 07:53, Stamatis Zampetakis  a
> écrit :
> >
> > Hello,
> >
> > At the moment, we can use both JUnit 4 and 5 annotations in our code
> base.
> > Lately, I spend some time on debugging a few test cases only to realize
> > that old and new APIs do not mix very well. If you encounter problems
> with
> > your annotations then consider checking your imports. The problem might
> lie
> > on the fact that you are using at the same time annotations from
> different
> > versions.
> >
> > Consider for example the following test.
> >
> > import org.junit.Assert;
> > import org.junit.Test;
> > import org.junit.jupiter.api.Disabled;
> >
> > public class SimpleTest {
> >
> >   @Test
> >   @Disabled
> >   public void test() {
> > Assert.fail("Should not run because it is disabled");
> >   }
> > }
> >
> > Contrary to what people might expect the test above will run and will
> fail
> > with an assertion error. Changing the imports (see below) will make the
> > test behave as expected.
> >
> > package org.apache.calcite;
> >
> > import org.junit.Assert;
> > import org.junit.jupiter.api.Test;
> > import org.junit.jupiter.api.Disabled;
> >
> > public class SimpleTest {
> >
> >   @Test
> >   @Disabled
> >   public void test() {
> > Assert.fail("Should not run because it is disabled");
> >   }
> > }
> >
> > Best,
> > Stamatis
>


Re: JProfiler license for committers

2019-12-02 Thread Andrei Sereda
> Stamatis, Andrei, have you considered JFR / async-profiler?
I'm happy to try it

On Sun, Dec 1, 2019 at 3:02 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> I find Java Flight Recorder and async-profiler to be good enough.
> Both tools are free to use, they both can be used to profile production
> systems, and they both produce actionable results.
>
> Stamatis, Andrei, have you considered JFR / async-profiler?
>
> Even though I do not object asking for a license, I do not feel comfortable
> promoting third-party profilers
> if it turns out nobody uses the license.
>
> AFAIK IntelliJ IDEA 2019.2+ has integration with both JFR and
> async-profiler (see https://www.jetbrains.com/help/idea/cpu-profiler.html
> ),
> however, I have not used it, and I happen to use the tools directly.
>
> Vladimir
>


Re: JProfiler license for committers

2019-12-01 Thread Andrei Sereda
I was also thinking getting open-source license for one of the profiling
tools.
I'm more familiar with YourKit but if JProfiler is comparable then don't
have any preference.

On Sat, Nov 30, 2019 at 1:57 AM Danny Chan  wrote:

> Personally I did not use JProfiler pretty much often, but adding the link
> to the page may give some help.
>
> Best,
> Danny Chan
> 在 2019年11月30日 +0800 AM4:50,Stamatis Zampetakis ,写道:
> > Hello,
> >
> > It seems that we can obtain a free license [1] for a certain number of
> > committers in exchange for a link to their product on our website.
> >
> > Personally, I am not a casual user of JProfiler but I happen to need it
> > from time to time and it would be more convenient to have a license for
> it.
> >
> > Is anybody else interested in a JProfiler license?
> >
> > How do you feel about adding a link in our website (possibly in develop
> > section)?
> >
> > Best,
> > Stamatis
> >
> > [1] https://www.ej-technologies.com/buy/jprofiler/openSource/enter
>


Re: CsvAdapter (Json content) from String / InputStream

2019-11-14 Thread Andrei Sereda
> I see that this feature request relates to Source.java and Sources.java,
which are in org.apache.calcite.util in core.
I'm not planning to change Source.java it already exposes Reader /
InputStream

> If you add some capability, it is fine to add It to the CSV adapter
example, but it is much more important that that capability exists in the
file adapter.
I will add to both. The general idea behind this change is that currently
CSV / File Adapter(s) require inputs to be File(s) or URL(s) which forces
users to create temporal resources manually (when their content is already
in-memory). If input to CSV / File adapter(s) is generic Readable [1] /
Reader [2] or InputStream it gives more flexibility to users.

[1] https://docs.oracle.com/javase/7/docs/api/java/lang/Readable.html
[2] https://docs.oracle.com/javase/7/docs/api/java/io/Reader.html


On Thu, Nov 14, 2019 at 2:45 PM Julian Hyde  wrote:

> I see that this feature request relates to Source.java and Sources.java,
> which are in org.apache.calcite.util in core.
>
> If you add some capability, it is fine to add It to the CSV adapter
> example, but it is much more important that that capability exists in the
> file adapter.
>
> Julian
>
>
> > On Nov 14, 2019, at 11:36 AM, Andrei Sereda  wrote:
> >
> > I think the change is straightforward (will not add complexity).
> >
> > On Thu, Nov 14, 2019 at 1:24 PM Julian Hyde  wrote:
> >
> >> Remember that CsvAdapter is in the “example” module. Keep it simple.
> >>
> >> The file adapter can also parse CSV files.
> >>
> >> Julian
> >>
> >>
> >>
> >>> On Nov 14, 2019, at 9:40 AM, Andrei Sereda  wrote:
> >>>
> >>> Hello,
> >>>
> >>> Source object already exposes Reader / InputStream API. Probably
> >>> JsonEnumerator can be changed to use those methods.
> >>>
> >>> Do you mind creating a JIRA ticket ? I'll take a look.
> >>>
> >>> Thanks,
> >>> Andrei.
> >>>
> >>> On Thu, Nov 14, 2019 at 7:45 AM Yanna elina <
> yannaelinasul...@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi guys ,
> >>>> I saw in the code that this nice adapter makes it possible to make SQL
> >>>> queries on the data JSON
> >>>>
> >>>>
> >>
> https://github.com/apache/calcite/tree/ab71c4cae5a5c3c7d979337a2d38ddaf271aa206/example/csv/src/main/java/org/apache/calcite/adapter/csv
> >>>>
> >>>> But  it's limited on File / URL.
> >>>> JsonTable constructor accepte only a Source object and this Source
> >> object
> >>>> can be construct only accross  a File / URL.
> >>>>
> >>>> it could be nice to have the possibility to make this source from
> >>>> ImputStream too .
> >>>>
> >>>> Creating a temp-file from an InputStream or String can be excesive.
> >>>>
> >>>> Thanks
> >>>>
> >>
> >>
>
>


Re: CsvAdapter (Json content) from String / InputStream

2019-11-14 Thread Andrei Sereda
I think the change is straightforward (will not add complexity).

On Thu, Nov 14, 2019 at 1:24 PM Julian Hyde  wrote:

> Remember that CsvAdapter is in the “example” module. Keep it simple.
>
> The file adapter can also parse CSV files.
>
> Julian
>
>
>
> > On Nov 14, 2019, at 9:40 AM, Andrei Sereda  wrote:
> >
> > Hello,
> >
> > Source object already exposes Reader / InputStream API. Probably
> > JsonEnumerator can be changed to use those methods.
> >
> > Do you mind creating a JIRA ticket ? I'll take a look.
> >
> > Thanks,
> > Andrei.
> >
> > On Thu, Nov 14, 2019 at 7:45 AM Yanna elina 
> > wrote:
> >
> >> Hi guys ,
> >> I saw in the code that this nice adapter makes it possible to make SQL
> >> queries on the data JSON
> >>
> >>
> https://github.com/apache/calcite/tree/ab71c4cae5a5c3c7d979337a2d38ddaf271aa206/example/csv/src/main/java/org/apache/calcite/adapter/csv
> >>
> >> But  it's limited on File / URL.
> >> JsonTable constructor accepte only a Source object and this Source
> object
> >> can be construct only accross  a File / URL.
> >>
> >> it could be nice to have the possibility to make this source from
> >> ImputStream too .
> >>
> >> Creating a temp-file from an InputStream or String can be excesive.
> >>
> >> Thanks
> >>
>
>


Re: CsvAdapter (Json content) from String / InputStream

2019-11-14 Thread Andrei Sereda
Hello,

Source object already exposes Reader / InputStream API. Probably
JsonEnumerator can be changed to use those methods.

Do you mind creating a JIRA ticket ? I'll take a look.

Thanks,
Andrei.

On Thu, Nov 14, 2019 at 7:45 AM Yanna elina 
wrote:

> Hi guys ,
> I saw in the code that this nice adapter makes it possible to make SQL
> queries on the data JSON
>
> https://github.com/apache/calcite/tree/ab71c4cae5a5c3c7d979337a2d38ddaf271aa206/example/csv/src/main/java/org/apache/calcite/adapter/csv
>
> But  it's limited on File / URL.
> JsonTable constructor accepte only a Source object and this Source object
> can be construct only accross  a File / URL.
>
> it could be nice to have the possibility to make this source from
> ImputStream too .
>
> Creating a temp-file from an InputStream or String can be excesive.
>
> Thanks
>


[jira] [Created] (CALCITE-3502) Upgrade Geode 1.6.0 -> 1.9.2

2019-11-13 Thread Andrei Sereda (Jira)
Andrei Sereda created CALCITE-3502:
--

 Summary: Upgrade Geode 1.6.0 -> 1.9.2
 Key: CALCITE-3502
 URL: https://issues.apache.org/jira/browse/CALCITE-3502
 Project: Calcite
  Issue Type: Improvement
  Components: geode-adapter
Reporter: Andrei Sereda


Upgrade geode to 1.9.2 (from 1.6.0)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: use calcite jdbc query mysql only return 10 records

2019-11-04 Thread Andrei Sereda
This was fixed in 1.18.0 (see CALCITE-2651). You can always manually set
LIMIT.

ES returns by default 10 records. Now calcite uses scrolling to fetch whole
index.


On Mon, Nov 4, 2019 at 2:43 PM James James  wrote:

> Dear
>
> Recently I  ticked in to a problem that use jdbc:calcite method get
> connection and execute query mysql and elasticssearch storage.  the results
> only return 10 records.  checked calcite codes and not found the problems.
> hope get help to fixed my problems
>
> calcite version is 1.17.0
>
> Thank in advance
>


Re: [ANNOUNCE] Danny Chan joins Calcite PMC

2019-10-30 Thread Andrei Sereda
Congrats, Danny!

On Wed, Oct 30, 2019 at 8:08 PM Julian Hyde  wrote:

> Congratulations, Danny! Thank you for all of your hard work on code,
> reviewing others' work, answering questions, and generally making our
> community welcoming to all!
>
> Julian
>
> On Wed, Oct 30, 2019 at 4:32 PM Michael Mior  wrote:
> >
> > Welcome on board Danny! Glad to have you.
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le mer. 30 oct. 2019 à 17:22, Francis Chuang
> >  a écrit :
> > >
> > > I'm pleased to announce that Danny has accepted an invitation to
> > > join the Calcite PMC. Danny has been a consistent and helpful
> > > figure in the Calcite community for which we are very grateful. We
> > > look forward to the continued contributions and support.
> > >
> > > Please join me in congratulating Danny!
> > >
> > > - Francis (on behalf of the Calcite PMC)
>


Re: Calcite - Model - MongoDB view

2019-10-15 Thread Andrei Sereda
Hi Neha Saini,

I'm afraid currently array access is not translated in mongo adapter.

There is a PR https://github.com/apache/calcite/pull/720 which needs to be
corrected.

Thanks,
Andrei.

On Mon, Oct 14, 2019 at 3:01 AM Danny Chan  wrote:

> Hi, Neha Saini
>
> What do you mean by MongoDB view, can you give more details, so we can
> give as much help if we can.
>
> Best,
> Danny Chan
> 在 2019年10月14日 +0800 PM2:21,Neha Saini ,写道:
> > Hi Team,
> >
> > Gentle reminder!
> >
> > Regards,
> > Neha Saini
> >
> > From: Neha Saini
> > Sent: Thursday, October 10, 2019 3:30 PM
> > To: dev@calcite.apache.org
> > Subject: Calcite - Model - MongoDB view
> >
> > Hi Team,
> >
> > Greetings for the day.
> >
> > I am working as a technical architect in HCL technologies.
> > I am doing a PoC on Apache calcite.
> >
> > Using MongoDB adapter I want to use calcite sql parser on mongo db
> database.
> > I am stuck at a point and need your help in the same.
> >
> > My data in Mongo DB has following structure:-
> > {
> > "_id": "tt0772249",
> > "title": "Palaces of a Queen",
> > "type": "movie",
> > "year": 1967,
> > "crew": [{
> > "name": "Micael Calunga",
> > "role": "actor"
> > }, {
> > "name": "Jordon Zonotti",
> > "role": "actress"
> > }
> > ]
> > }
> >
> > I want to create view with column title, year, crew.name
> > But in modql.json , I am not able to MAP array of objects, like
> crew.name 0th element, or nth element.
> >
> > "tables": [
> > {
> > "name": "movie",
> > "type": "view",
> > "sql": "select cast(_MAP['title'] AS varchar(100)) AS title,
> cast(_MAP['year'] AS varchar(4)) AS year, cast(_MAP['crew.name'][0] AS
> varchar(20)) AS crewname from \"mongo_raw\".\"movie\""
> > },
> >
> >
> > In the GIThib code, we have zip example, but zip file is a flat json,
> but json I am using is embedded , hence not able to use the example.
> >
> > I would really appreciate some help.
> >
> > Thanks!
> >
> > Regards,
> > Neha Saini
> >
> > ::DISCLAIMER::
> > 
> > The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> > 
>


Re: Apache Calcite Geode

2019-10-12 Thread Andrei Sereda
Hi Viquar Khan,

Currently write operations (UPDATE / DELETE / INSERT) are not supported by
geode-calcite adapter. You need to load data using native API then query it
using Calcite.

There is some documentation on our website:
https://calcite.apache.org/docs/geode_adapter.html but it is by no means
comprehensive. Let me know if you'd like to improve it and we'll happily
accept your contribution.

Regards,
Andrei.






On Fri, Oct 11, 2019 at 10:04 PM vaquar khan  wrote:

> Hi All,
>
> I am looking good examples or document /tutorials/sample code for Apache
> Calcite Geode,unfortunately noting is available on net , only one  talk
> from  tzolv.
>
> I have raised  following question few month back and now able to connect
> now  .
>
>
> https://stackoverflow.com/questions/49411169/apache-calcite-geode-jdbc-adapte-not-working-with-gemfire-8-x-and-9-x/58343449#58343449
>
>
> I am try to use Apache spark Job to load data on gemfire using Apache
> Calcite Geode adopter .
> I am also interested to create good reference for other users they are
> facing same problems .
>
> Any help greatly appreciated.
>
> Regards,
> Viquar khan
>


Re: Cannot connect to ES

2019-10-07 Thread Andrei Sereda
HTTPS support was added recently (see CALCITE-3335
). To be released in
1.22

Currently ES configuration expects hostname without schema prefix (eg.
https://).





On Mon, Oct 7, 2019 at 9:52 PM Danny Chan  wrote:

> It seems that the host name “https://.com” can not be resolved by the
> java net api, do you validate it with java code on your machine ?
>
> Best,
> Danny Chan
> 在 2019年10月8日 +0800 AM8:13,Badrul Chowdhury  >,写道:
> > Hi,
> >
> > I am trying to use the Calcite-ES adapter to connect to a remote ES
> > instance (logs below). I can connect to the endpoint, but I have to use
> > credentials (login/pass). Is there and option in the model definition to
> > include those fields? The documentation does not mention any..
> >
> > Thoughts?
> >
> > Exception:
> > [..]
> >
> > *Caused by: java.net.UnknownHostException: https://.com: nodename
> nor
> > servname provided, or not known* at
> > java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> > at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
> > at
> java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
> > at java.net.InetAddress.getAllByName0(InetAddress.java:1277)
> > at java.net.InetAddress.getAllByName(InetAddress.java:1193)
> > at java.net.InetAddress.getAllByName(InetAddress.java:1127)
> > at
> >
> org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
> > [..]
> >
> > Model file:
> > {
> > "version": "1.0",
> > "defaultSchema": "elasticsearch",
> > "schemas": [
> > {
> > "type": "custom",
> > "name": "elasticsearch",
> > "factory":
> > "org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
> > "operand": {
> > "coordinates": "{'https://.com': 9200}"
> > // "coordinates": "{'127.0.0.1': 9200}"
> > }
> > }
> > ]
> > }
> > --
> >
> > Cheers,
> > Badrul
>


Re: How to connect es5 in the latest mainline code?

2019-09-30 Thread Andrei Sereda
Hi Chen,

Please use the latest calcite version 1.21 which has dependency on ES 7.x
low-level rest client.

We have removed elasticsearch5 and elasticsearch2 maven modules in favor of
a single elasticsearch (which uses rest-client in favor of transport
client) in CALCITE-2376
 (fixed
in v1.17).

Thanks,
Andrei.

On Mon, Sep 30, 2019 at 8:37 AM chen cui  wrote:

> Hi:
> I want to know how to connect to es5 in the latest mainline code. I
> read the es5 theme in the official documentation and mailing list, but I
> didn't find the answer.
> I tried to connect es5 in the latest mainline code, but it
> failed.
> I modified the es version in pom.xml to be the same as the
> version in the calcite 1.16-elasticsearch5 directory (5.5.2), but the
> compiler will report an error with the error message: Could not find
> artifact org.elasticsearch.client:elasticsearch-rest -client:jar:5.5.2 in
> central (https://repo.maven.apache.org/maven2)
> My model.json is as follows:
> [image: 蓝信图片_lx_clip1569831497074.jpg]
>
> Thank you very much for your reply!
>


Re: [DISCUSS] Small contributions

2019-09-27 Thread Andrei Sereda
I presume 3rd party library upgrades should go through regular process
(jira/PR etc.) ?

Dependency upgrade is not considered  "small change" since impact is
greater than just a "typo fix".


On Thu, Sep 26, 2019 at 1:47 PM Julian Hyde  wrote:

> A few points.
>
> I don’t like the term “hot fix”. A hot fix has an existing meaning[1] - it
> is a patch you apply to your binaries. Let’s not use that term.
>
> Let’s define “small contributions” as contributions that do not modify
> code and therefore will not break anything, do not need a test or
> documentation change, and do not need a CI run.
>
> I am in favor of accepting small contributions. I wasn’t previously.
>
> We can have guidelines about how to label these small contributions (e.g.
> git labels, certain words in the commit message or PR description). But we
> shouldn’t expect or require contributors to follow those guidelines. By
> their nature, these contributors have not had time to read all of our
> policy documents.
>
> Reviewers must know what our policy is, and should massage commit messages
> tot conform to policy.
>
> These kinds of changes are, by definition, very small and simple. A
> committer can review, approve, fix up, and push to master, and close the PR
> in one go. Five minutes. If the PR requires a back-and-forth then it is not
> a “simple” change.
>
> We should not require a JIRA case.
>
> We not apply the usual policy of appending the contributor’s name to the
> commit message. A typical commit message would be “Fix a comment”.
>
> Release manager should remove these kinds of trivial changes from the
> release notes. They add nothing to the release notes.
>
> These kinds of changes do earn “merit” - the basis on which we make people
> committers - but they earn less merit than a bug fix, a new feature, a
> detailed response to a question on the dev list, or a conference talk. I
> don’t want people to believe that they can earn committership by fixing 100
> typos.
>
> There can be problems if a community over-relies on small PRs. In
> particular, there is a project in the Incubator that has only one or two
> regular developers but receives hundreds of contributions a few lines long
> via PRs. The discussion occurs in the PRs, and contributors rarely make
> more than 1 or 2 contributions. The problem for the project is that there
> is no emergent “community”. This is a serious problem for that project, and
> obviously we do not have that problem. Still, there is a side effect to the
> back-and-forth discussion to get a change accepted, namely that the
> individuals get to know each other. We don’t want to lose that.
>
>
> Julian
>
> [1] https://en.wikipedia.org/wiki/Hotfix <
> https://en.wikipedia.org/wiki/Hotfix>
>
>
>
>
> > On Sep 26, 2019, at 5:17 AM, Michael Mior  wrote:
> >
> > I thought about a label, but I think it's probably more productive to
> > just review the change immediately if it really is something trivial.
> > The problem is that labels can only be applied by committers. That's
> > why I suggested asking those who submit PRs to include something in
> > the PR title. If others think a label would help though, I'm not
> > opposed to it.
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le jeu. 26 sept. 2019 à 07:28, TANG Wen-hui
> >  a écrit :
> >>
> >> I agree that we should accept these small changes but not create JIRA
> for them.
> >> In my opinion, maybe we can label the PR of these small changes.  And
> process them at regular intervals in case of forgetting.
> >>
> >> best,
> >> --
> >> wenhui
> >>
> >>
> >>
> >> winifred.wenhui.t...@gmail.com
> >>
> >> From: Haisheng Yuan
> >> Date: 2019-09-26 10:17
> >> To: Francis Chuang; dev@calcite.apache.org (dev@calcite.apache.org)
> >> Subject: Re: Re: [DISCUSS] Small contributions
> >>> most of the time, the author of the fix would  have moved on and have
> >> forgotten about it, resulting in the improvement falling through the
> cracks.
> >>
> >> Make sense. I think our current position worth reconsidering and I
> >> agree with Francis.
> >>
> >> - Haisheng
> >>
> >> --
> >> 发件人:Francis Chuang
> >> 日 期:2019年09月26日 09:20:49
> >> 收件人:
> >> 主 题:Re: [DISCUSS] Small contributions
> >>
> >> From personal experience, I think we should accept these small changes.
> >> I have had lots of  cases where I am reading code or documentation on
> >> Github and found small errors or typos that are easy to fix, so I'd edit
> >> directly in Github and open a PR. These changes do improve the codebase
> >> and fix errors that could be misleading or confuse future maintainers
> >> and users.
> >>
> >> It might be easy to say that we want to combine all these small changes
> >> into a bigger change, but most of the time, the author of the fix would
> >> have moved on and have forgotten about it, resulting in the improvement
> >> falling through the cracks. It also makes the amount of effort required
> >> to start 

Re: How to connect es5 in the latest mainline code?

2019-09-26 Thread Andrei Sereda
Hello,

What version of calcite are you using ? Can you try with latest 1.21
 release ?
elasticsearch5 module has been removed a while ago.

Also we recommend using ES 6.2+ with calcite.

Thanks,
Andrei.


On Thu, Sep 26, 2019 at 9:31 AM ipconfig  wrote:

> Hi:
> I want to know how to connect to es5 in the latest mainline code. I
> read the es5 theme in the official documentation and mailing list, but I
> didn't find the answer.
> I tried to connect es5 in the latest mainline code, but it failed.
> I modified the es version in pom.xml to be the same as the version
> in the calcite 1.16-elasticsearch5 directory (5.5.2), but the compiler will
> report an error with the error message: Could not find artifact
> org.elasticsearch.client:elasticsearch-rest -client:jar:5.5.2 in central (
> https://repo.maven.apache.org/maven2)
> My model.json is as follows: {
>"version": "1.0",
>"defaultSchema": "elasticsearch",
>"schemas": [
>  {
>"type": "custom",
>"name": "elasticsearch",
>"factory":
> "org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
>"operand": {
>  "coordinates": "{'10.95.26.17': 9200}"
>}
>  }
>]
> }
>
>
>
>
>
>
>
>
>
>
>
>


Re: Re: [ANNOUNCE] New committer: Julian Feinauer

2019-09-18 Thread Andrei Sereda
Congratulations, Julian !

On Tue, Sep 17, 2019 at 11:26 PM Amit Chavan  wrote:

> Congrats, Julian !!
>
> On Tue, Sep 17, 2019 at 8:12 PM XING JIN  wrote:
>
> > Congrats, Julian !
> > You are well deserved ~
> >
> > Haisheng Yuan  于2019年9月18日周三 上午10:38写道:
> >
> > > Congrats, Julian!
> > >
> > > - Haisheng
> > >
> > > --
> > > 发件人:Chunwei Lei
> > > 日 期:2019年09月18日 10:30:31
> > > 收件人:
> > > 主 题:Re: [ANNOUNCE] New committer: Julian Feinauer
> > >
> > > Congratulations, Julian!
> > >
> > >
> > >
> > > Best,
> > > Chunwei
> > >
> > >
> > > On Wed, Sep 18, 2019 at 9:24 AM Danny Chan 
> wrote:
> > >
> > > > Congratulations, Muhammad ! Welcome to join us ! Thanks for your huge
> > > > contribution for the Match Recognize.
> > > >
> > > > Best,
> > > > Danny Chan
> > > > 在 2019年9月18日 +0800 AM5:55,Francis Chuang  > >,写道:
> > > > > Apache Calcite's Project Management Committee (PMC) has invited
> > Julian
> > > > > Feinauer to become a committer, and we are pleased to announce that
> > he
> > > > > has accepted.
> > > > >
> > > > > Julian is an active contributor to the Calcite code base and has
> been
> > > > > active on the mailing list answering questions, participating in
> > > > > discussions and voting for releases.
> > > > >
> > > > > Julian, welcome, thank you for your contributions, and we look
> > forward
> > > > > your further interactions with the community! If you wish, please
> > feel
> > > > > free to tell us more about yourself and what you are working on.
> > > > >
> > > > > Francis (on behalf of the Apache Calcite PMC)
> > > >
> > >
> > >
> >
>


Re: [ANNOUNCE] New committer: Muhammad Gelbana

2019-09-18 Thread Andrei Sereda
Congrats, Muhammad!

On Tue, Sep 17, 2019 at 11:26 PM Amit Chavan  wrote:

> Congratulations, Muhammad !!
>
> On Tue, Sep 17, 2019 at 8:10 PM XING JIN  wrote:
>
> > Congrats, Muhammad !
> >
> > 王炎林 <1989yanlinw...@163.com> 于2019年9月18日周三 上午10:38写道:
> >
> > > Congratulations, Muhammad!
> > >
> > >
> > > Best,
> > > Yanlin
> > >
> > >
> > >
> > >
> > >
> > >
> > > At 2019-09-18 05:58:53, "Francis Chuang" 
> > wrote:
> > > >Apache Calcite's Project Management Committee (PMC) has invited
> Muhammad
> > > >Gelbana to become a committer, and we are pleased to announce that he
> > > >has accepted.
> > > >
> > > >Muhammad is an active contributor and has contributed numerous patches
> > > >to Calcite. He has also been extremely active on the mailing list,
> > > >helping out new users and participating in design discussions.
> > > >
> > > >Muhammad, welcome, thank you for your contributions, and we look
> forward
> > > >your further interactions with the community! If you wish, please feel
> > > >free to tell us more about yourself and what you are working on.
> > > >
> > > >Francis (on behalf of the Apache Calcite PMC)
> > >
> >
>


Re: [VOTE] Release apache-calcite-1.21.0 (release candidate 1)

2019-09-10 Thread Andrei Sereda
+1 (non-binding)

Minor correction: sha256 of source distribution
(apache-calcite-1.21.0-src.tar.gz) is
ccd10264f89a84bc750837cc2d0e66b7d74a81dd825d0a88f501153d4745eee3

Environment: Mac OS X Java version: 11.0.4, vendor: AdoptOpenJDK Maven 3.6.1

mvn clean install - OK
sh256 check - OK
GPG check - OK
Release notes - OK

On Tue, Sep 10, 2019 at 11:25 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> +1
>
> There are OsAdapterTest.testPs and testPsDistinct failures, however they
> are well known.
>
> Vladimir
>


Re: Virtual key signing party

2019-08-12 Thread Andrei Sereda
Didn't know about your key.

Since you're release manager for 1.20 we can meet one-to-one (or arrange
new party next week). I'll sign your key.

On Mon, Aug 12, 2019 at 10:47 AM Stamatis Zampetakis 
wrote:

> Thanks Andrei, just a small precision; my old key has been compromised so I
> was forced to revoke it.
> The one I send earlier is my new key.
>
> On Mon, Aug 12, 2019 at 4:43 PM Andrei Sereda  wrote:
>
> > If there are more people interested I'll join the party (this or next
> > week).
> >
> > Stamatis and I signed each others keys a while ago.
> >
> > pub   rsa4096 2018-10-18 [SC]
> >   25E7 0310 6B1B 3D7B 1050  32BD C41C FDDF ED34 C028
> > uid   [ultimate] Andrei Sereda (CODE SIGNING KEY) <
> > ser...@apache.org
> > >
> > uid   [ultimate] Andrei Sereda 
> > uid   [ultimate] asereda-gs (Andrei Sereda) <
> > 25229979+asereda...@users.noreply.github.com>
> > uid   [ultimate] Andrei Sereda 
> > sub   rsa4096 2018-10-18 [E]
> >
> >
> > On Mon, Aug 12, 2019 at 10:17 AM Stamatis Zampetakis 
> > wrote:
> >
> > > Given that nobody expressed interest to participate in the sessions
> > today,
> > > I suggest to postpone the party.
> > > We can still try to find some other slots this week; if there is any
> > > interest please reply to this thread otherwise we can try again in a
> > couple
> > > of months.
> > >
> > > On Sat, Aug 10, 2019 at 11:24 AM Francis Chuang <
> > francischu...@apache.org>
> > > wrote:
> > >
> > > > Thanks for organizing this, Stamatis! I don't think I'll be able to
> > > > attend these sessions this time, but I do encourage everyone else to
> > > > attend including committers. If you're from another Apache project,
> > feel
> > > > free to attend too.
> > > >
> > > > Francis
> > > >
> > > > On 10/08/2019 6:26 pm, Stamatis Zampetakis wrote:
> > > > > Hello,
> > > > >
> > > > > The last virtual key signing party [1] was a few months ago [2]. I
> > > would
> > > > > propose to hold another one in the next few days. We could have the
> > > > > following two slots:
> > > > >
> > > > >   * Slot A https://tinyurl.com/y3coduw7
> > > > >   * Slot B https://tinyurl.com/yxqmq429
> > > > >
> > > > > hoping that at least one would be convenient for people in the US,
> > > > Europe,
> > > > > and Asia.
> > > > >
> > > > > If you would like to attend, please reply to this thread with your
> > > public
> > > > > keys' fingerprint (gpg --fingerprint) and the slot you plan to join
> > > > before
> > > > > the respective meeting.
> > > > >
> > > > > pub   rsa4096 2019-03-15 [SC] [expires: 2023-03-15]
> > > > >0474 9577 FD93 4674 B9CD  45C5 D77C 3383 F192 7570
> > > > > uid   [ultimate] Stamatis Zampetakis 
> > > > > uid   [ultimate] Stamatis Zampetakis 
> > > > > sub   rsa4096 2019-03-15 [E] [expires: 2023-03-15]
> > > > >
> > > > > To verify your identity, please bring with you a government issued
> ID
> > > > > (preferably passport).
> > > > >
> > > > > As a reminder of the procedure have a look in the notes [1] took by
> > > > Francis
> > > > > during a previous party!
> > > > >
> > > > > Best,
> > > > > Stamatis
> > > > >
> > > > > [1]
> > > > >
> > > >
> > >
> >
> http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html
> > > > > [2]
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/af8403a495c5067a7f7dfcb684d24b3362db0331e315b745492d748e@%3Cdev.calcite.apache.org%3E
> > > > > [3] https://gist.github.com/F21/b0e8c62c49dfab267ff1d0c6af39ab84
> > > > >
> > > >
> > >
> >
>


Re: Virtual key signing party

2019-08-12 Thread Andrei Sereda
If there are more people interested I'll join the party (this or next week).

Stamatis and I signed each others keys a while ago.

pub   rsa4096 2018-10-18 [SC]
  25E7 0310 6B1B 3D7B 1050  32BD C41C FDDF ED34 C028
uid   [ultimate] Andrei Sereda (CODE SIGNING KEY) 
uid   [ultimate] Andrei Sereda 
uid   [ultimate] asereda-gs (Andrei Sereda) <
25229979+asereda...@users.noreply.github.com>
uid   [ultimate] Andrei Sereda 
sub   rsa4096 2018-10-18 [E]


On Mon, Aug 12, 2019 at 10:17 AM Stamatis Zampetakis 
wrote:

> Given that nobody expressed interest to participate in the sessions today,
> I suggest to postpone the party.
> We can still try to find some other slots this week; if there is any
> interest please reply to this thread otherwise we can try again in a couple
> of months.
>
> On Sat, Aug 10, 2019 at 11:24 AM Francis Chuang 
> wrote:
>
> > Thanks for organizing this, Stamatis! I don't think I'll be able to
> > attend these sessions this time, but I do encourage everyone else to
> > attend including committers. If you're from another Apache project, feel
> > free to attend too.
> >
> > Francis
> >
> > On 10/08/2019 6:26 pm, Stamatis Zampetakis wrote:
> > > Hello,
> > >
> > > The last virtual key signing party [1] was a few months ago [2]. I
> would
> > > propose to hold another one in the next few days. We could have the
> > > following two slots:
> > >
> > >   * Slot A https://tinyurl.com/y3coduw7
> > >   * Slot B https://tinyurl.com/yxqmq429
> > >
> > > hoping that at least one would be convenient for people in the US,
> > Europe,
> > > and Asia.
> > >
> > > If you would like to attend, please reply to this thread with your
> public
> > > keys' fingerprint (gpg --fingerprint) and the slot you plan to join
> > before
> > > the respective meeting.
> > >
> > > pub   rsa4096 2019-03-15 [SC] [expires: 2023-03-15]
> > >0474 9577 FD93 4674 B9CD  45C5 D77C 3383 F192 7570
> > > uid   [ultimate] Stamatis Zampetakis 
> > > uid   [ultimate] Stamatis Zampetakis 
> > > sub   rsa4096 2019-03-15 [E] [expires: 2023-03-15]
> > >
> > > To verify your identity, please bring with you a government issued ID
> > > (preferably passport).
> > >
> > > As a reminder of the procedure have a look in the notes [1] took by
> > Francis
> > > during a previous party!
> > >
> > > Best,
> > > Stamatis
> > >
> > > [1]
> > >
> >
> http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html
> > > [2]
> > >
> >
> https://lists.apache.org/thread.html/af8403a495c5067a7f7dfcb684d24b3362db0331e315b745492d748e@%3Cdev.calcite.apache.org%3E
> > > [3] https://gist.github.com/F21/b0e8c62c49dfab267ff1d0c6af39ab84
> > >
> >
>


  1   2   3   4   >