You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Andrei Sereda <an...@sereda.cc> on 2020/01/22 16:07:40 UTC
Re: [DISCUSS] Towards Calcite 1.22
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 <jh...@apache.org> 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 <eo...@gmail.com>
> wrote:
> >
> > Andrei
> >
> > Il mar 3 dic 2019, 08:21 Rui Wang <amaliujia@apache.org <mailto:
> amaliujia@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 <ch...@gmail.com>
> 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 <an...@sereda.cc> 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
Posted by Danny Chan <yu...@gmail.com>.
Sure, we can do a switch. My next release is 1.24
Best,
Danny Chan
在 2020年2月12日 +0800 AM1:09，Andrei Sereda <an...@sereda.cc>，写道：
> Thanks for stepping in Danny. Can I take your release ?
>
> On Mon, Feb 10, 2020 at 2:34 PM Julian Hyde <jh...@apache.org> 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 <eo...@gmail.com> wrote:
> > >
> > > Il Dom 9 Feb 2020, 08:41 Stamatis Zampetakis <za...@gmail.com> 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.vladimir@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
Posted by Andrei Sereda <an...@sereda.cc>.
Thanks for stepping in Danny. Can I take your release ?
On Mon, Feb 10, 2020 at 2:34 PM Julian Hyde <jh...@apache.org> 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 <eo...@gmail.com> wrote:
> >
> > Il Dom 9 Feb 2020, 08:41 Stamatis Zampetakis <za...@gmail.com> 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.vladimir@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
Posted by Julian Hyde <jh...@apache.org>.
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 <eo...@gmail.com> wrote:
>
> Il Dom 9 Feb 2020, 08:41 Stamatis Zampetakis <za...@gmail.com> 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.vladimir@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
Posted by Enrico Olivelli <eo...@gmail.com>.
Il Dom 9 Feb 2020, 08:41 Stamatis Zampetakis <za...@gmail.com> 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.vladimir@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
Posted by Stamatis Zampetakis <za...@gmail.com>.
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.) 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.vladimir@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
Posted by Vladimir Sitnikov <si...@gmail.com>.
>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
Posted by Enrico Olivelli <eo...@gmail.com>.
Are current -SNAPSHOT packages on repository.apache.org up to date ?
I would like to test my projects in CI against current master
Having a release would be great at this point
Enrico
Il giorno sab 8 feb 2020 alle ore 06:06 Danny Chan
<yu...@gmail.com> ha scritto:
>
> I can do that.
>
> Andrei Sereda <an...@sereda.cc>于2020年2月8日 周六上午6:18写道：
>
> > Is there anyone willing to swap a Calcite release with me ?
> >
> > On Fri, Feb 7, 2020 at 12:41 PM Andrei Sereda <an...@sereda.cc> 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 <jh...@apache.org> 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 <an...@sereda.cc> 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 <jh...@apache.org> 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 <eolivelli@gmail.com
> > >
> > >> > > wrote:
> > >> > > >
> > >> > > > Andrei
> > >> > > >
> > >> > > > Il mar 3 dic 2019, 08:21 Rui Wang <amaliujia@apache.org <mailto:
> > >> > > amaliujia@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 <
> > chunwei.leii@gmail.com
> > >> >
> > >> > > 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 <an...@sereda.cc>
> > >> 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
Posted by Danny Chan <yu...@gmail.com>.
I can do that.
Andrei Sereda <an...@sereda.cc>于2020年2月8日 周六上午6:18写道：
> Is there anyone willing to swap a Calcite release with me ?
>
> On Fri, Feb 7, 2020 at 12:41 PM Andrei Sereda <an...@sereda.cc> 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 <jh...@apache.org> 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 <an...@sereda.cc> 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 <jh...@apache.org> 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 <eolivelli@gmail.com
> >
> >> > > wrote:
> >> > > >
> >> > > > Andrei
> >> > > >
> >> > > > Il mar 3 dic 2019, 08:21 Rui Wang <amaliujia@apache.org <mailto:
> >> > > amaliujia@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 <
> chunwei.leii@gmail.com
> >> >
> >> > > 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 <an...@sereda.cc>
> >> 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
Posted by Andrei Sereda <an...@sereda.cc>.
Is there anyone willing to swap a Calcite release with me ?
On Fri, Feb 7, 2020 at 12:41 PM Andrei Sereda <an...@sereda.cc> 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 <jh...@apache.org> 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 <an...@sereda.cc> 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 <jh...@apache.org> 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 <eo...@gmail.com>
>> > > wrote:
>> > > >
>> > > > Andrei
>> > > >
>> > > > Il mar 3 dic 2019, 08:21 Rui Wang <amaliujia@apache.org <mailto:
>> > > amaliujia@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 <chunwei.leii@gmail.com
>> >
>> > > 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 <an...@sereda.cc>
>> 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
Posted by Andrei Sereda <an...@sereda.cc>.
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 <jh...@apache.org> 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 <an...@sereda.cc> 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 <jh...@apache.org> 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 <eo...@gmail.com>
> > > wrote:
> > > >
> > > > Andrei
> > > >
> > > > Il mar 3 dic 2019, 08:21 Rui Wang <amaliujia@apache.org <mailto:
> > > amaliujia@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 <ch...@gmail.com>
> > > 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 <an...@sereda.cc>
> 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
Posted by Julian Hyde <jh...@apache.org>.
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 <an...@sereda.cc> 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 <jh...@apache.org> 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 <eo...@gmail.com>
> > wrote:
> > >
> > > Andrei
> > >
> > > Il mar 3 dic 2019, 08:21 Rui Wang <amaliujia@apache.org <mailto:
> > amaliujia@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 <ch...@gmail.com>
> > 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 <an...@sereda.cc> 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>
> >