Re: [DISCUSS] Towards Calcite 1.37.0

[Hongyu Guo]

PR solves two problems at once. I initially started by
> > >>>> solving 3522,
> > >>>>>>> but then I realized that the solution uncovers many bugs in 6169,
> > >>>> so I
> > >>>>>>> solved that one as well. Just days ago someone filed
> > >>>>>>> https://issues.apache.org/jira/browse/CALCITE-6366 for this very
> > >>>> issue.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>*
> > >>>>>>> 3522 solves the problem where Calcite limits DECIMAL literals to
> > >>>> 64 bits.
> > >>>>>>> However, even the default DECIMAL implementation in Calcite
> > >>>> supports 128
> > >>>>>>> bits, and some SQL dialects go even further (Postgres has
> billions
> > >>>> of
> > >>>>>>> digits of precision). With this change there are no limits to the
> > >>>> precision
> > >>>>>>> of a DECIMAL literal, and the limits come from the Calcite
> > >>>> typeSystem in
> > >>>>>>> use.
> > >>>>>>>*
> > >>>>>>> 6366 solves another problem related to the first issue described
> > >>>> above,
> > >>>>>>> 6322, where narrowing casts (that convert a numeric value to a
> > >>>> numeric
> > >>>>>>> value with fewer bits) do not report errors on overflow. This is
> > >>>> another
> > >>>>>>> long-standing bug in Calcite.
> > >>>>>>>
> > >>>>>>> I will try to break this into two separate PRs that have to be
> > >>>> merged in
> > >>>>>>> order; I will start with 6169. Maybe this will make it more
> > >>>> palatable for
> > >>>>>>> the reviewers.
> > >>>>>>>
> > >>>>>>> Besides these 3 PRs, I have one more PR that I would like to land
> > >>>> in 1.37,
> > >>>>>>> which is not a bugfix, but a new feature, so perhaps it's less
> > >>>> urgent.
> > >>>>>>> [CALCITE-6071] RexCall should carry source position information
> > >>>> for runtime
> > >>>>>>> error reporting<https://github.com/apache/calcite/pull/3506> is
> a
> > >>>>>>> relatively large PR, which adds source position information to
> > >>>> RexCall and
> > >>>>>>> AggregateCall nodes. This is useful when a runtime error happens,
> > >>>> like a
> > >>>>>>> division by 0. Using this information the runtime can report
> which
> > >>>>>>> division in the program failed. Without this, debugging may be
> very
> > >>>>>>> difficult, especially when the program is large and can have many
> > >>>> division
> > >>>>>>> operations, some hidden in operations like STDDEV_SAMP. This PR
> > >>>> does not
> > >>>>>>> affect in any way the semantics of Calcite programs, it's a no-op
> > >>>> for
> > >>>>>>> almost everyone. But it does touch many files, because it has to
> > >>>> add new
> > >>>>>>> constructors for these classes and make sure that the information
> > >>>> is
> > >>>>>>> available when the constructors are being invoked. At this point
> > >>>> there are
> > >>>>>>> no users of this information in the Calcite codebase, but once
> the
> > >>>> PR is
> > >>>>>>> merged we can use it even in the existing evaluator (that will
> > >>>> also require
> > >>>>>>> significant work, since the evaluator itself does not expect
> source
> > >>>>>>> position information).
> > >>>>>>>
> > >>>>>>> Thank you,
> > >>>>>>> Mihai
> > >>>>>>>
> > >>>>>>> 
> > >>>>>>> From: Francis Chuang 
> > >>>>>>> Sent: Wednesday, April 17, 2024 9:05 PM
> > &

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

 more time which I can use to help with
> >>>>>> review.
> >>>>>> I would suggest to set a deadline like end of Saturday/begin of
> >>>> Sunday
> >>>>>> in order to have an RC on Monday (IIRC anyway because of holidays
> >>>> voting
> >>>>>> period was usually extended)
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Apr 18, 2024 at 6:55 PM Mihai Budiu 
> >>>> wrote:
> >>>>>>
> >>>>>>> I have a few PR that I would like to land in 1.37 which have
> >>>> received no
> >>>>>>> reviews.
> >>>>>>> Three of them resolve bugs which I consider quite important.
> >>>>>>> Let me describe them briefly, maybe this will help convince
> >>>> someone to
> >>>>>>> contribute the effort of reviewing.
> >>>>>>> Normally this kind of discussion is made inside of JIRA, but I
> >>>> noticed
> >>>>>>> that if one is not following a particular JIRA ticket, they will
> >>>> never see
> >>>>>>> the conversation.
> >>>>>>>
> >>>>>>> [CALCITE-6322] Casts to DECIMAL types are ignored<
> >>>>>>> https://github.com/apache/calcite/pull/3733>
> >>>>>>>
> >>>>>>> Code like (CAST x AS DECIMAL(5, 2)) is treated by Calcite like a
> >>>> NOOP. I
> >>>>>>> consider this as a major bug, which has been open for a very long
> >>>> time.
> >>>>>>> This PR handles the cases where X is a numeric type.
> >>>>>>>
> >>>>>>> [CALCITE-2067] RexLiteral cannot represent accurately floating
> >>>> point
> >>>>>>> values, including NaN, Infinity<
> >>>>>>> https://github.com/apache/calcite/pull/3663>
> >>>>>>>
> >>>>>>> Calcite uses BigDecimal values to represent floating point
> >>>> literals. This
> >>>>>>> has two problems:
> >>>>>>>
> >>>>>>>*
> >>>>>>> some FP constants cannot be represented exactly, leading to subtle
> >>>>>>> rounding errors in computations that are performed at
> >>>> compilation-time
> >>>>>>>*
> >>>>>>> FP literals cannot represent special FP values, like NaN
> >>>>>>>
> >>>>>>> This PR switches the representation of FP literals to use Java
> >>>>>>> Double/Float values. This is a breaking change, because it changes
> >>>> the
> >>>>>>> semantics of some programs. However, I claim that these programs
> >>>> were
> >>>>>>> initially incorrect.
> >>>>>>>
> >>>>>>> [CALCITE-3522] Sql validator limits decimal literals to 64 bits and
> >>>>>>> [CALCITE-6169] EnumUtils.convert does not implement the correct
> >>>> SQL cast
> >>>>>>> semantics<https://github.com/apache/calcite/pull/3589>
> >>>>>>>
> >>>>>>> This PR solves two problems at once. I initially started by
> >>>> solving 3522,
> >>>>>>> but then I realized that the solution uncovers many bugs in 6169,
> >>>> so I
> >>>>>>> solved that one as well. Just days ago someone filed
> >>>>>>> https://issues.apache.org/jira/browse/CALCITE-6366 for this very
> >>>> issue.
> >>>>>>>
> >>>>>>>
> >>>>>>>    *
> >>>>>>> 3522 solves the problem where Calcite limits DECIMAL literals to
> >>>> 64 bits.
> >>>>>>> However, even the default DECIMAL implementation in Calcite
> >>>> supports 128
> >>>>>>> bits, and some SQL dialects go even further (Postgres has billions
> >>>> of
> >>>>>>> digits of precision). With this change there are no limits to the
> >>>> precision
> >>>>>>> of a DECIMAL 

Re: [DISCUSS] Towards Calcite 1.37.0

[Francis Chuang]

t;

This PR solves two problems at once. I initially started by

solving 3522,

but then I realized that the solution uncovers many bugs in 6169,

so I

solved that one as well. Just days ago someone filed
https://issues.apache.org/jira/browse/CALCITE-6366 for this very

issue.



   *
3522 solves the problem where Calcite limits DECIMAL literals to

64 bits.

However, even the default DECIMAL implementation in Calcite

supports 128

bits, and some SQL dialects go even further (Postgres has billions

of

digits of precision). With this change there are no limits to the

precision

of a DECIMAL literal, and the limits come from the Calcite

typeSystem in

use.
   *
6366 solves another problem related to the first issue described

above,

6322, where narrowing casts (that convert a numeric value to a

numeric

value with fewer bits) do not report errors on overflow. This is

another

long-standing bug in Calcite.

I will try to break this into two separate PRs that have to be

merged in

order; I will start with 6169. Maybe this will make it more

palatable for

the reviewers.

Besides these 3 PRs, I have one more PR that I would like to land

in 1.37,

which is not a bugfix, but a new feature, so perhaps it's less

urgent.

[CALCITE-6071] RexCall should carry source position information

for runtime

error reporting<https://github.com/apache/calcite/pull/3506> is a
relatively large PR, which adds source position information to

RexCall and

AggregateCall nodes. This is useful when a runtime error happens,

like a

division by 0. Using this information the runtime can report which
division in the program failed. Without this, debugging may be very
difficult, especially when the program is large and can have many

division

operations, some hidden in operations like STDDEV_SAMP. This PR

does not

affect in any way the semantics of Calcite programs, it's a no-op

for

almost everyone. But it does touch many files, because it has to

add new

constructors for these classes and make sure that the information

is

available when the constructors are being invoked. At this point

there are

no users of this information in the Calcite codebase, but once the

PR is

merged we can use it even in the existing evaluator (that will

also require

significant work, since the evaluator itself does not expect source
position information).

Thank you,
Mihai


From: Francis Chuang 
Sent: Wednesday, April 17, 2024 9:05 PM
To: dev@calcite.apache.org 
Subject: Re: [DISCUSS] Towards Calcite 1.37.0

I agree that it would be good to cut a release soon, as there

haven't

been too many commits in the last couple of days.

I think it would be great for Sergey to set a deadline for the last
commits to be accepted, close the main branch and start the release
process. As Sergey is RM for the release, it would be best for him

to

set the date as to when the main branch should be closed.

On 18/04/2024 12:55 pm, Benchao Li wrote:

May I ask what's the status of releasing 1.37.0, since upgrading

to

Avatica 1.25 has been done 9 days ago, I would assume that there

are

no blockers now?

I know many of us would like to clear some of the PR backlog

before a

release, however it would be better to have some balance between
clearing PR backlog and rolling out releases regularly. It's

been a

bit more than 5 months since our last Calcite release (1.36.0 on
2023-11-10), and 2 months after I kicked off this thread.

What do you think?

Francis Chuang  于2024年4月9日周二 05:49写道：


+1 I think that's a good idea and will help clear some of the PR

backlog.


On 9/04/2024 7:47 am, Sergey Nuyanzin wrote:

I think it would would make sense if they are already ready to

be

merged

Thanks for the suggestion

what do you think if we reserve about 2-3 days for this

activity?

I would also encourage committers to merge such bug fixes if

any




On Mon, Apr 8, 2024 at 11:36 PM Mihai Budiu 

wrote:



Can we do another quick pass over the open PRs, or is it too

late?

Since we started the process a bunch of bug fixes were

submitted, and

some

of them may be easy to merge.

Mihai

From: Sergey Nuyanzin 
Sent: Monday, April 8, 2024 2:32 PM
To: dev@calcite.apache.org 
Subject: Re: [DISCUSS] Towards Calcite 1.37.0

Upgrade of Avatica is done at CALCITE-6356 [1], thanks a lot

for

review

You can go forward with PRs if there still any

If there is no objections  I'm going to start steps to

prepare and

create

an RC tomorrow

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

On Mon, Apr 8, 2024 at 8:14 PM Mihai Budiu 

wrote:



Hello,

I am assuming that (one of) the next steps towards 1.37 will

be a PR

which

upgrades Avatica to 1.25.
Is anyone working on that?
After that is merged I plan to merge two PRs which re-enable

the

tests

that

were disabled temporarily.

Thank you,
Mihai


On Mon, Mar 18, 2024 at 9:48 AM Mihai Budiu <

mbu...@gmail.com>

wrote:



This would 

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

f one is not following a particular JIRA ticket, they will
>>> never see
>>> > > > the conversation.
>>> > > >
>>> > > > [CALCITE-6322] Casts to DECIMAL types are ignored<
>>> > > > https://github.com/apache/calcite/pull/3733>
>>> > > >
>>> > > > Code like (CAST x AS DECIMAL(5, 2)) is treated by Calcite like a
>>> NOOP. I
>>> > > > consider this as a major bug, which has been open for a very long
>>> time.
>>> > > > This PR handles the cases where X is a numeric type.
>>> > > >
>>> > > > [CALCITE-2067] RexLiteral cannot represent accurately floating
>>> point
>>> > > > values, including NaN, Infinity<
>>> > > > https://github.com/apache/calcite/pull/3663>
>>> > > >
>>> > > > Calcite uses BigDecimal values to represent floating point
>>> literals. This
>>> > > > has two problems:
>>> > > >
>>> > > >   *
>>> > > > some FP constants cannot be represented exactly, leading to subtle
>>> > > > rounding errors in computations that are performed at
>>> compilation-time
>>> > > >   *
>>> > > > FP literals cannot represent special FP values, like NaN
>>> > > >
>>> > > > This PR switches the representation of FP literals to use Java
>>> > > > Double/Float values. This is a breaking change, because it changes
>>> the
>>> > > > semantics of some programs. However, I claim that these programs
>>> were
>>> > > > initially incorrect.
>>> > > >
>>> > > > [CALCITE-3522] Sql validator limits decimal literals to 64 bits and
>>> > > > [CALCITE-6169] EnumUtils.convert does not implement the correct
>>> SQL cast
>>> > > > semantics<https://github.com/apache/calcite/pull/3589>
>>> > > >
>>> > > > This PR solves two problems at once. I initially started by
>>> solving 3522,
>>> > > > but then I realized that the solution uncovers many bugs in 6169,
>>> so I
>>> > > > solved that one as well. Just days ago someone filed
>>> > > > https://issues.apache.org/jira/browse/CALCITE-6366 for this very
>>> issue.
>>> > > >
>>> > > >
>>> > > >   *
>>> > > > 3522 solves the problem where Calcite limits DECIMAL literals to
>>> 64 bits.
>>> > > > However, even the default DECIMAL implementation in Calcite
>>> supports 128
>>> > > > bits, and some SQL dialects go even further (Postgres has billions
>>> of
>>> > > > digits of precision). With this change there are no limits to the
>>> precision
>>> > > > of a DECIMAL literal, and the limits come from the Calcite
>>> typeSystem in
>>> > > > use.
>>> > > >   *
>>> > > > 6366 solves another problem related to the first issue described
>>> above,
>>> > > > 6322, where narrowing casts (that convert a numeric value to a
>>> numeric
>>> > > > value with fewer bits) do not report errors on overflow. This is
>>> another
>>> > > > long-standing bug in Calcite.
>>> > > >
>>> > > > I will try to break this into two separate PRs that have to be
>>> merged in
>>> > > > order; I will start with 6169. Maybe this will make it more
>>> palatable for
>>> > > > the reviewers.
>>> > > >
>>> > > > Besides these 3 PRs, I have one more PR that I would like to land
>>> in 1.37,
>>> > > > which is not a bugfix, but a new feature, so perhaps it's less
>>> urgent.
>>> > > > [CALCITE-6071] RexCall should carry source position information
>>> for runtime
>>> > > > error reporting<https://github.com/apache/calcite/pull/3506> is a
>>> > > > relatively large PR, which adds source position information to
>>> RexCall and
>>> > > > AggregateCall nodes. This is useful when a runtime error happens,
>>> like a
>>> > > > division by 0. Using this information the runtime can report which
>>> > > > division in the program failed. Without this, debugging may be very
>>> > > > 

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

; values, including NaN, Infinity<
>> > > > https://github.com/apache/calcite/pull/3663>
>> > > >
>> > > > Calcite uses BigDecimal values to represent floating point
>> literals. This
>> > > > has two problems:
>> > > >
>> > > >   *
>> > > > some FP constants cannot be represented exactly, leading to subtle
>> > > > rounding errors in computations that are performed at
>> compilation-time
>> > > >   *
>> > > > FP literals cannot represent special FP values, like NaN
>> > > >
>> > > > This PR switches the representation of FP literals to use Java
>> > > > Double/Float values. This is a breaking change, because it changes
>> the
>> > > > semantics of some programs. However, I claim that these programs
>> were
>> > > > initially incorrect.
>> > > >
>> > > > [CALCITE-3522] Sql validator limits decimal literals to 64 bits and
>> > > > [CALCITE-6169] EnumUtils.convert does not implement the correct SQL
>> cast
>> > > > semantics<https://github.com/apache/calcite/pull/3589>
>> > > >
>> > > > This PR solves two problems at once. I initially started by solving
>> 3522,
>> > > > but then I realized that the solution uncovers many bugs in 6169,
>> so I
>> > > > solved that one as well. Just days ago someone filed
>> > > > https://issues.apache.org/jira/browse/CALCITE-6366 for this very
>> issue.
>> > > >
>> > > >
>> > > >   *
>> > > > 3522 solves the problem where Calcite limits DECIMAL literals to 64
>> bits.
>> > > > However, even the default DECIMAL implementation in Calcite
>> supports 128
>> > > > bits, and some SQL dialects go even further (Postgres has billions
>> of
>> > > > digits of precision). With this change there are no limits to the
>> precision
>> > > > of a DECIMAL literal, and the limits come from the Calcite
>> typeSystem in
>> > > > use.
>> > > >   *
>> > > > 6366 solves another problem related to the first issue described
>> above,
>> > > > 6322, where narrowing casts (that convert a numeric value to a
>> numeric
>> > > > value with fewer bits) do not report errors on overflow. This is
>> another
>> > > > long-standing bug in Calcite.
>> > > >
>> > > > I will try to break this into two separate PRs that have to be
>> merged in
>> > > > order; I will start with 6169. Maybe this will make it more
>> palatable for
>> > > > the reviewers.
>> > > >
>> > > > Besides these 3 PRs, I have one more PR that I would like to land
>> in 1.37,
>> > > > which is not a bugfix, but a new feature, so perhaps it's less
>> urgent.
>> > > > [CALCITE-6071] RexCall should carry source position information for
>> runtime
>> > > > error reporting<https://github.com/apache/calcite/pull/3506> is a
>> > > > relatively large PR, which adds source position information to
>> RexCall and
>> > > > AggregateCall nodes. This is useful when a runtime error happens,
>> like a
>> > > > division by 0. Using this information the runtime can report which
>> > > > division in the program failed. Without this, debugging may be very
>> > > > difficult, especially when the program is large and can have many
>> division
>> > > > operations, some hidden in operations like STDDEV_SAMP. This PR
>> does not
>> > > > affect in any way the semantics of Calcite programs, it's a no-op
>> for
>> > > > almost everyone. But it does touch many files, because it has to
>> add new
>> > > > constructors for these classes and make sure that the information is
>> > > > available when the constructors are being invoked. At this point
>> there are
>> > > > no users of this information in the Calcite codebase, but once the
>> PR is
>> > > > merged we can use it even in the existing evaluator (that will also
>> require
>> > > > significant work, since the evaluator itself does not expect source
>> > > > position information).
>> > > >
>> > > > Thank you,
>> > > > Mihai
>> > > >
>> > >

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

 > > > solved that one as well. Just days ago someone filed
> > > > https://issues.apache.org/jira/browse/CALCITE-6366 for this very
> issue.
> > > >
> > > >
> > > >   *
> > > > 3522 solves the problem where Calcite limits DECIMAL literals to 64
> bits.
> > > > However, even the default DECIMAL implementation in Calcite supports
> 128
> > > > bits, and some SQL dialects go even further (Postgres has billions of
> > > > digits of precision). With this change there are no limits to the
> precision
> > > > of a DECIMAL literal, and the limits come from the Calcite
> typeSystem in
> > > > use.
> > > >   *
> > > > 6366 solves another problem related to the first issue described
> above,
> > > > 6322, where narrowing casts (that convert a numeric value to a
> numeric
> > > > value with fewer bits) do not report errors on overflow. This is
> another
> > > > long-standing bug in Calcite.
> > > >
> > > > I will try to break this into two separate PRs that have to be
> merged in
> > > > order; I will start with 6169. Maybe this will make it more
> palatable for
> > > > the reviewers.
> > > >
> > > > Besides these 3 PRs, I have one more PR that I would like to land in
> 1.37,
> > > > which is not a bugfix, but a new feature, so perhaps it's less
> urgent.
> > > > [CALCITE-6071] RexCall should carry source position information for
> runtime
> > > > error reporting<https://github.com/apache/calcite/pull/3506> is a
> > > > relatively large PR, which adds source position information to
> RexCall and
> > > > AggregateCall nodes. This is useful when a runtime error happens,
> like a
> > > > division by 0. Using this information the runtime can report which
> > > > division in the program failed. Without this, debugging may be very
> > > > difficult, especially when the program is large and can have many
> division
> > > > operations, some hidden in operations like STDDEV_SAMP. This PR does
> not
> > > > affect in any way the semantics of Calcite programs, it's a no-op for
> > > > almost everyone. But it does touch many files, because it has to add
> new
> > > > constructors for these classes and make sure that the information is
> > > > available when the constructors are being invoked. At this point
> there are
> > > > no users of this information in the Calcite codebase, but once the
> PR is
> > > > merged we can use it even in the existing evaluator (that will also
> require
> > > > significant work, since the evaluator itself does not expect source
> > > > position information).
> > > >
> > > > Thank you,
> > > > Mihai
> > > >
> > > > 
> > > > From: Francis Chuang 
> > > > Sent: Wednesday, April 17, 2024 9:05 PM
> > > > To: dev@calcite.apache.org 
> > > > Subject: Re: [DISCUSS] Towards Calcite 1.37.0
> > > >
> > > > I agree that it would be good to cut a release soon, as there haven't
> > > > been too many commits in the last couple of days.
> > > >
> > > > I think it would be great for Sergey to set a deadline for the last
> > > > commits to be accepted, close the main branch and start the release
> > > > process. As Sergey is RM for the release, it would be best for him to
> > > > set the date as to when the main branch should be closed.
> > > >
> > > > On 18/04/2024 12:55 pm, Benchao Li wrote:
> > > > > May I ask what's the status of releasing 1.37.0, since upgrading to
> > > > > Avatica 1.25 has been done 9 days ago, I would assume that there
> are
> > > > > no blockers now?
> > > > >
> > > > > I know many of us would like to clear some of the PR backlog
> before a
> > > > > release, however it would be better to have some balance between
> > > > > clearing PR backlog and rolling out releases regularly. It's been a
> > > > > bit more than 5 months since our last Calcite release (1.36.0 on
> > > > > 2023-11-10), and 2 months after I kicked off this thread.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Francis Chuang  于2024年4月9日周二 05:49写道：
> > > > >>
> > > > >> +1 I think that's a g

Re: [DISCUSS] Towards Calcite 1.37.0

[Benchao Li]

> > 6366 solves another problem related to the first issue described above,
> > > 6322, where narrowing casts (that convert a numeric value to a numeric
> > > value with fewer bits) do not report errors on overflow. This is another
> > > long-standing bug in Calcite.
> > >
> > > I will try to break this into two separate PRs that have to be merged in
> > > order; I will start with 6169. Maybe this will make it more palatable for
> > > the reviewers.
> > >
> > > Besides these 3 PRs, I have one more PR that I would like to land in 1.37,
> > > which is not a bugfix, but a new feature, so perhaps it's less urgent.
> > > [CALCITE-6071] RexCall should carry source position information for 
> > > runtime
> > > error reporting<https://github.com/apache/calcite/pull/3506> is a
> > > relatively large PR, which adds source position information to RexCall and
> > > AggregateCall nodes. This is useful when a runtime error happens, like a
> > > division by 0. Using this information the runtime can report which
> > > division in the program failed. Without this, debugging may be very
> > > difficult, especially when the program is large and can have many division
> > > operations, some hidden in operations like STDDEV_SAMP. This PR does not
> > > affect in any way the semantics of Calcite programs, it's a no-op for
> > > almost everyone. But it does touch many files, because it has to add new
> > > constructors for these classes and make sure that the information is
> > > available when the constructors are being invoked. At this point there are
> > > no users of this information in the Calcite codebase, but once the PR is
> > > merged we can use it even in the existing evaluator (that will also 
> > > require
> > > significant work, since the evaluator itself does not expect source
> > > position information).
> > >
> > > Thank you,
> > > Mihai
> > >
> > > 
> > > From: Francis Chuang 
> > > Sent: Wednesday, April 17, 2024 9:05 PM
> > > To: dev@calcite.apache.org 
> > > Subject: Re: [DISCUSS] Towards Calcite 1.37.0
> > >
> > > I agree that it would be good to cut a release soon, as there haven't
> > > been too many commits in the last couple of days.
> > >
> > > I think it would be great for Sergey to set a deadline for the last
> > > commits to be accepted, close the main branch and start the release
> > > process. As Sergey is RM for the release, it would be best for him to
> > > set the date as to when the main branch should be closed.
> > >
> > > On 18/04/2024 12:55 pm, Benchao Li wrote:
> > > > May I ask what's the status of releasing 1.37.0, since upgrading to
> > > > Avatica 1.25 has been done 9 days ago, I would assume that there are
> > > > no blockers now?
> > > >
> > > > I know many of us would like to clear some of the PR backlog before a
> > > > release, however it would be better to have some balance between
> > > > clearing PR backlog and rolling out releases regularly. It's been a
> > > > bit more than 5 months since our last Calcite release (1.36.0 on
> > > > 2023-11-10), and 2 months after I kicked off this thread.
> > > >
> > > > What do you think?
> > > >
> > > > Francis Chuang  于2024年4月9日周二 05:49写道：
> > > >>
> > > >> +1 I think that's a good idea and will help clear some of the PR
> > > backlog.
> > > >>
> > > >> On 9/04/2024 7:47 am, Sergey Nuyanzin wrote:
> > > >>> I think it would would make sense if they are already ready to be
> > > merged
> > > >>> Thanks for the suggestion
> > > >>>
> > > >>> what do you think if we reserve about 2-3 days for this activity?
> > > >>> I would also encourage committers to merge such bug fixes if any
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Mon, Apr 8, 2024 at 11:36 PM Mihai Budiu  wrote:
> > > >>>
> > > >>>> Can we do another quick pass over the open PRs, or is it too late?
> > > >>>> Since we started the process a bunch of bug fixes were submitted, and
> > > some
> > > >>>> of them may be easy to merge.
> > > >>>>
> > > >>>> Mihai
> > > >>>> 
> &g

Re: [DISCUSS] Towards Calcite 1.37.0

[Stamatis Zampetakis]

ot a bugfix, but a new feature, so perhaps it's less urgent.
> > [CALCITE-6071] RexCall should carry source position information for runtime
> > error reporting<https://github.com/apache/calcite/pull/3506> is a
> > relatively large PR, which adds source position information to RexCall and
> > AggregateCall nodes. This is useful when a runtime error happens, like a
> > division by 0. Using this information the runtime can report which
> > division in the program failed. Without this, debugging may be very
> > difficult, especially when the program is large and can have many division
> > operations, some hidden in operations like STDDEV_SAMP. This PR does not
> > affect in any way the semantics of Calcite programs, it's a no-op for
> > almost everyone. But it does touch many files, because it has to add new
> > constructors for these classes and make sure that the information is
> > available when the constructors are being invoked. At this point there are
> > no users of this information in the Calcite codebase, but once the PR is
> > merged we can use it even in the existing evaluator (that will also require
> > significant work, since the evaluator itself does not expect source
> > position information).
> >
> > Thank you,
> > Mihai
> >
> > 
> > From: Francis Chuang 
> > Sent: Wednesday, April 17, 2024 9:05 PM
> > To: dev@calcite.apache.org 
> > Subject: Re: [DISCUSS] Towards Calcite 1.37.0
> >
> > I agree that it would be good to cut a release soon, as there haven't
> > been too many commits in the last couple of days.
> >
> > I think it would be great for Sergey to set a deadline for the last
> > commits to be accepted, close the main branch and start the release
> > process. As Sergey is RM for the release, it would be best for him to
> > set the date as to when the main branch should be closed.
> >
> > On 18/04/2024 12:55 pm, Benchao Li wrote:
> > > May I ask what's the status of releasing 1.37.0, since upgrading to
> > > Avatica 1.25 has been done 9 days ago, I would assume that there are
> > > no blockers now?
> > >
> > > I know many of us would like to clear some of the PR backlog before a
> > > release, however it would be better to have some balance between
> > > clearing PR backlog and rolling out releases regularly. It's been a
> > > bit more than 5 months since our last Calcite release (1.36.0 on
> > > 2023-11-10), and 2 months after I kicked off this thread.
> > >
> > > What do you think?
> > >
> > > Francis Chuang  于2024年4月9日周二 05:49写道：
> > >>
> > >> +1 I think that's a good idea and will help clear some of the PR
> > backlog.
> > >>
> > >> On 9/04/2024 7:47 am, Sergey Nuyanzin wrote:
> > >>> I think it would would make sense if they are already ready to be
> > merged
> > >>> Thanks for the suggestion
> > >>>
> > >>> what do you think if we reserve about 2-3 days for this activity?
> > >>> I would also encourage committers to merge such bug fixes if any
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Apr 8, 2024 at 11:36 PM Mihai Budiu  wrote:
> > >>>
> > >>>> Can we do another quick pass over the open PRs, or is it too late?
> > >>>> Since we started the process a bunch of bug fixes were submitted, and
> > some
> > >>>> of them may be easy to merge.
> > >>>>
> > >>>> Mihai
> > >>>> 
> > >>>> From: Sergey Nuyanzin 
> > >>>> Sent: Monday, April 8, 2024 2:32 PM
> > >>>> To: dev@calcite.apache.org 
> > >>>> Subject: Re: [DISCUSS] Towards Calcite 1.37.0
> > >>>>
> > >>>> Upgrade of Avatica is done at CALCITE-6356 [1], thanks a lot for
> > review
> > >>>> You can go forward with PRs if there still any
> > >>>>
> > >>>> If there is no objections  I'm going to start steps to prepare and
> > create
> > >>>> an RC tomorrow
> > >>>>
> > >>>> [1] https://issues.apache.org/jira/browse/CALCITE-6356
> > >>>>
> > >>>> On Mon, Apr 8, 2024 at 8:14 PM Mihai Budiu  wrote:
> > >>>>
> > >>>>> Hello,
> > >>>>>
> > >>>>> I am assuming that (one of) the next st

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

Thanks Benchao and Francis for pushing
you are right we need to finally make an RC

Thanks Mihai for driving this work
Starting tomorrow I will have more time which I can use to help with
review.
I would suggest to set a deadline like end of Saturday/begin of Sunday
in order to have an RC on Monday (IIRC anyway because of holidays voting
period was usually extended)

WDYT?




On Thu, Apr 18, 2024 at 6:55 PM Mihai Budiu  wrote:

> I have a few PR that I would like to land in 1.37 which have received no
> reviews.
> Three of them resolve bugs which I consider quite important.
> Let me describe them briefly, maybe this will help convince someone to
> contribute the effort of reviewing.
> Normally this kind of discussion is made inside of JIRA, but I noticed
> that if one is not following a particular JIRA ticket, they will never see
> the conversation.
>
> [CALCITE-6322] Casts to DECIMAL types are ignored<
> https://github.com/apache/calcite/pull/3733>
>
> Code like (CAST x AS DECIMAL(5, 2)) is treated by Calcite like a NOOP. I
> consider this as a major bug, which has been open for a very long time.
> This PR handles the cases where X is a numeric type.
>
> [CALCITE-2067] RexLiteral cannot represent accurately floating point
> values, including NaN, Infinity<
> https://github.com/apache/calcite/pull/3663>
>
> Calcite uses BigDecimal values to represent floating point literals. This
> has two problems:
>
>   *
> some FP constants cannot be represented exactly, leading to subtle
> rounding errors in computations that are performed at compilation-time
>   *
> FP literals cannot represent special FP values, like NaN
>
> This PR switches the representation of FP literals to use Java
> Double/Float values. This is a breaking change, because it changes the
> semantics of some programs. However, I claim that these programs were
> initially incorrect.
>
> [CALCITE-3522] Sql validator limits decimal literals to 64 bits and
> [CALCITE-6169] EnumUtils.convert does not implement the correct SQL cast
> semantics<https://github.com/apache/calcite/pull/3589>
>
> This PR solves two problems at once. I initially started by solving 3522,
> but then I realized that the solution uncovers many bugs in 6169, so I
> solved that one as well. Just days ago someone filed
> https://issues.apache.org/jira/browse/CALCITE-6366 for this very issue.
>
>
>   *
> 3522 solves the problem where Calcite limits DECIMAL literals to 64 bits.
> However, even the default DECIMAL implementation in Calcite supports 128
> bits, and some SQL dialects go even further (Postgres has billions of
> digits of precision). With this change there are no limits to the precision
> of a DECIMAL literal, and the limits come from the Calcite typeSystem in
> use.
>   *
> 6366 solves another problem related to the first issue described above,
> 6322, where narrowing casts (that convert a numeric value to a numeric
> value with fewer bits) do not report errors on overflow. This is another
> long-standing bug in Calcite.
>
> I will try to break this into two separate PRs that have to be merged in
> order; I will start with 6169. Maybe this will make it more palatable for
> the reviewers.
>
> Besides these 3 PRs, I have one more PR that I would like to land in 1.37,
> which is not a bugfix, but a new feature, so perhaps it's less urgent.
> [CALCITE-6071] RexCall should carry source position information for runtime
> error reporting<https://github.com/apache/calcite/pull/3506> is a
> relatively large PR, which adds source position information to RexCall and
> AggregateCall nodes. This is useful when a runtime error happens, like a
> division by 0. Using this information the runtime can report which​
> division in the program failed. Without this, debugging may be very
> difficult, especially when the program is large and can have many division
> operations, some hidden in operations like STDDEV_SAMP. This PR does not
> affect in any way the semantics of Calcite programs, it's a no-op for
> almost everyone. But it does touch many files, because it has to add new
> constructors for these classes and make sure that the information is
> available when the constructors are being invoked. At this point there are
> no users of this information in the Calcite codebase, but once the PR is
> merged we can use it even in the existing evaluator (that will also require
> significant work, since the evaluator itself does not expect source
> position information).
>
> Thank you,
> Mihai
>
> 
> From: Francis Chuang 
> Sent: Wednesday, April 17, 2024 9:05 PM
> To: dev@calcite.apache.org 
> Subject: Re: [DISCUSS] Towards Calcite 1.37.0
>
> I agree that it would be good 

Re: [DISCUSS] Towards Calcite 1.37.0

[Mihai Budiu]

I have a few PR that I would like to land in 1.37 which have received no 
reviews.
Three of them resolve bugs which I consider quite important.
Let me describe them briefly, maybe this will help convince someone to 
contribute the effort of reviewing.
Normally this kind of discussion is made inside of JIRA, but I noticed that if 
one is not following a particular JIRA ticket, they will never see the 
conversation.

[CALCITE-6322] Casts to DECIMAL types are 
ignored<https://github.com/apache/calcite/pull/3733>

Code like (CAST x AS DECIMAL(5, 2)) is treated by Calcite like a NOOP. I 
consider this as a major bug, which has been open for a very long time. This PR 
handles the cases where X is a numeric type.

[CALCITE-2067] RexLiteral cannot represent accurately floating point values, 
including NaN, Infinity<https://github.com/apache/calcite/pull/3663>

Calcite uses BigDecimal values to represent floating point literals. This has 
two problems:

  *
some FP constants cannot be represented exactly, leading to subtle rounding 
errors in computations that are performed at compilation-time
  *
FP literals cannot represent special FP values, like NaN

This PR switches the representation of FP literals to use Java Double/Float 
values. This is a breaking change, because it changes the semantics of some 
programs. However, I claim that these programs were initially incorrect.

[CALCITE-3522] Sql validator limits decimal literals to 64 bits and 
[CALCITE-6169] EnumUtils.convert does not implement the correct SQL cast 
semantics<https://github.com/apache/calcite/pull/3589>

This PR solves two problems at once. I initially started by solving 3522, but 
then I realized that the solution uncovers many bugs in 6169, so I solved that 
one as well. Just days ago someone filed 
https://issues.apache.org/jira/browse/CALCITE-6366 for this very issue.


  *
3522 solves the problem where Calcite limits DECIMAL literals to 64 bits. 
However, even the default DECIMAL implementation in Calcite supports 128 bits, 
and some SQL dialects go even further (Postgres has billions of digits of 
precision). With this change there are no limits to the precision of a DECIMAL 
literal, and the limits come from the Calcite typeSystem in use.
  *
6366 solves another problem related to the first issue described above, 6322, 
where narrowing casts (that convert a numeric value to a numeric value with 
fewer bits) do not report errors on overflow. This is another long-standing bug 
in Calcite.

I will try to break this into two separate PRs that have to be merged in order; 
I will start with 6169. Maybe this will make it more palatable for the 
reviewers.

Besides these 3 PRs, I have one more PR that I would like to land in 1.37, 
which is not a bugfix, but a new feature, so perhaps it's less urgent. 
[CALCITE-6071] RexCall should carry source position information for runtime 
error reporting<https://github.com/apache/calcite/pull/3506> is a relatively 
large PR, which adds source position information to RexCall and AggregateCall 
nodes. This is useful when a runtime error happens, like a division by 0. Using 
this information the runtime can report which​ division in the program failed. 
Without this, debugging may be very difficult, especially when the program is 
large and can have many division operations, some hidden in operations like 
STDDEV_SAMP. This PR does not affect in any way the semantics of Calcite 
programs, it's a no-op for almost everyone. But it does touch many files, 
because it has to add new constructors for these classes and make sure that the 
information is available when the constructors are being invoked. At this point 
there are no users of this information in the Calcite codebase, but once the PR 
is merged we can use it even in the existing evaluator (that will also require 
significant work, since the evaluator itself does not expect source position 
information).

Thank you,
Mihai


From: Francis Chuang 
Sent: Wednesday, April 17, 2024 9:05 PM
To: dev@calcite.apache.org 
Subject: Re: [DISCUSS] Towards Calcite 1.37.0

I agree that it would be good to cut a release soon, as there haven't
been too many commits in the last couple of days.

I think it would be great for Sergey to set a deadline for the last
commits to be accepted, close the main branch and start the release
process. As Sergey is RM for the release, it would be best for him to
set the date as to when the main branch should be closed.

On 18/04/2024 12:55 pm, Benchao Li wrote:
> May I ask what's the status of releasing 1.37.0, since upgrading to
> Avatica 1.25 has been done 9 days ago, I would assume that there are
> no blockers now?
>
> I know many of us would like to clear some of the PR backlog before a
> release, however it would be better to have some balance between
> clearing PR backlog and rolling out releases regularly. It's been a
> bit more than 5 months since 

Re: [DISCUSS] Towards Calcite 1.37.0

[Francis Chuang]

I agree that it would be good to cut a release soon, as there haven't 
been too many commits in the last couple of days.


I think it would be great for Sergey to set a deadline for the last 
commits to be accepted, close the main branch and start the release 
process. As Sergey is RM for the release, it would be best for him to 
set the date as to when the main branch should be closed.


On 18/04/2024 12:55 pm, Benchao Li wrote:

May I ask what's the status of releasing 1.37.0, since upgrading to
Avatica 1.25 has been done 9 days ago, I would assume that there are
no blockers now?

I know many of us would like to clear some of the PR backlog before a
release, however it would be better to have some balance between
clearing PR backlog and rolling out releases regularly. It's been a
bit more than 5 months since our last Calcite release (1.36.0 on
2023-11-10), and 2 months after I kicked off this thread.

What do you think?

Francis Chuang  于2024年4月9日周二 05:49写道：


+1 I think that's a good idea and will help clear some of the PR backlog.

On 9/04/2024 7:47 am, Sergey Nuyanzin wrote:

I think it would would make sense if they are already ready to be merged
Thanks for the suggestion

what do you think if we reserve about 2-3 days for this activity?
I would also encourage committers to merge such bug fixes if any



On Mon, Apr 8, 2024 at 11:36 PM Mihai Budiu  wrote:


Can we do another quick pass over the open PRs, or is it too late?
Since we started the process a bunch of bug fixes were submitted, and some
of them may be easy to merge.

Mihai

From: Sergey Nuyanzin 
Sent: Monday, April 8, 2024 2:32 PM
To: dev@calcite.apache.org 
Subject: Re: [DISCUSS] Towards Calcite 1.37.0

Upgrade of Avatica is done at CALCITE-6356 [1], thanks a lot for review
You can go forward with PRs if there still any

If there is no objections  I'm going to start steps to prepare and create
an RC tomorrow

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

On Mon, Apr 8, 2024 at 8:14 PM Mihai Budiu  wrote:


Hello,

I am assuming that (one of) the next steps towards 1.37 will be a PR

which

upgrades Avatica to 1.25.
Is anyone working on that?
After that is merged I plan to merge two PRs which re-enable the tests

that

were disabled temporarily.

Thank you,
Mihai


On Mon, Mar 18, 2024 at 9:48 AM Mihai Budiu  wrote:


This would be great, I am fixing two very basic bugs.
Was busy with some other stuff, so I didn't have time to figure out how

to

submit the PRs so that they pass, if anyone has more detailed

instructions

I would be very happy. Otherwise I will dig into it.

Mihai
--
*From:* Francis Chuang 
*Sent:* Sunday, March 17, 2024 2:44 PM
*To:* dev@calcite.apache.org 
*Subject:* Re: [DISCUSS] Towards Calcite 1.37.0

Hey everyone,

I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282

(no

corresponding PRs in the Calcite repo yet).

The corresponding PRs in the Avatica repo are:
- https://github.com/apache/calcite-avatica/pull/238
- https://github.com/apache/calcite-avatica/pull/241

As the issue will require changes to both Calcite and Avatica in a
coordinated fashion, what do you guys think about releasing Avatica
1.25.0 first? I can be RM for the Avatica release.

Mihai, can you please confirm if this approach works for you?

Discussion for getting changes simultaneously into both Avatica and
Calcite is here [2].

Francis

[1] https://github.com/apache/calcite/pull/3708
[2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq

On 13/03/2024 10:07 pm, Benchao Li wrote:

Thank you, Hongyu, for volunteering to be a release manager.

What's worth to mention is that to be a release manager does not
require PMC membership nor being a committer, and it is a good chance
to be involved in community activities apart from code/discussion,
which would be a good additional credit for being considered as
committer or PMC member candidate.

Hongyu Guo  于2024年3月13日周三 11:29写道：


I would like to take on the role of RM for one release

On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
alessandro.solima...@gmail.com> wrote:


Hey Sergey,
thanks for being the release manager for 1.37.0.

I have added fixVersion=1.37.0 to CALCITE-2040
<https://issues.apache.org/jira/browse/CALCITE-2040>, as its

associated PR

<https://github.com/apache/calcite/pull/3666> is in good shape

IMO,

and we

are trying to get it done shortly with Hongyu.

Best regards,
Alessandro

On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin 

wrote:



Updates about 1.37.0 releasing

According to our Jira dashboard [1] and Github [2], there
are 17 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.37.0

backlog and merge the PRs which are in a good state. I'd propose

to

aim for about 2 weeks to release 1.37.0, this will give us about
some time to clean up pending PRs for the next version. W

Re: [DISCUSS] Towards Calcite 1.37.0

[Benchao Li]

May I ask what's the status of releasing 1.37.0, since upgrading to
Avatica 1.25 has been done 9 days ago, I would assume that there are
no blockers now?

I know many of us would like to clear some of the PR backlog before a
release, however it would be better to have some balance between
clearing PR backlog and rolling out releases regularly. It's been a
bit more than 5 months since our last Calcite release (1.36.0 on
2023-11-10), and 2 months after I kicked off this thread.

What do you think?

Francis Chuang  于2024年4月9日周二 05:49写道：
>
> +1 I think that's a good idea and will help clear some of the PR backlog.
>
> On 9/04/2024 7:47 am, Sergey Nuyanzin wrote:
> > I think it would would make sense if they are already ready to be merged
> > Thanks for the suggestion
> >
> > what do you think if we reserve about 2-3 days for this activity?
> > I would also encourage committers to merge such bug fixes if any
> >
> >
> >
> > On Mon, Apr 8, 2024 at 11:36 PM Mihai Budiu  wrote:
> >
> >> Can we do another quick pass over the open PRs, or is it too late?
> >> Since we started the process a bunch of bug fixes were submitted, and some
> >> of them may be easy to merge.
> >>
> >> Mihai
> >> ________
> >> From: Sergey Nuyanzin 
> >> Sent: Monday, April 8, 2024 2:32 PM
> >> To: dev@calcite.apache.org 
> >> Subject: Re: [DISCUSS] Towards Calcite 1.37.0
> >>
> >> Upgrade of Avatica is done at CALCITE-6356 [1], thanks a lot for review
> >> You can go forward with PRs if there still any
> >>
> >> If there is no objections  I'm going to start steps to prepare and create
> >> an RC tomorrow
> >>
> >> [1] https://issues.apache.org/jira/browse/CALCITE-6356
> >>
> >> On Mon, Apr 8, 2024 at 8:14 PM Mihai Budiu  wrote:
> >>
> >>> Hello,
> >>>
> >>> I am assuming that (one of) the next steps towards 1.37 will be a PR
> >> which
> >>> upgrades Avatica to 1.25.
> >>> Is anyone working on that?
> >>> After that is merged I plan to merge two PRs which re-enable the tests
> >> that
> >>> were disabled temporarily.
> >>>
> >>> Thank you,
> >>> Mihai
> >>>
> >>>
> >>> On Mon, Mar 18, 2024 at 9:48 AM Mihai Budiu  wrote:
> >>>
> >>>> This would be great, I am fixing two very basic bugs.
> >>>> Was busy with some other stuff, so I didn't have time to figure out how
> >>> to
> >>>> submit the PRs so that they pass, if anyone has more detailed
> >>> instructions
> >>>> I would be very happy. Otherwise I will dig into it.
> >>>>
> >>>> Mihai
> >>>> --
> >>>> *From:* Francis Chuang 
> >>>> *Sent:* Sunday, March 17, 2024 2:44 PM
> >>>> *To:* dev@calcite.apache.org 
> >>>> *Subject:* Re: [DISCUSS] Towards Calcite 1.37.0
> >>>>
> >>>> Hey everyone,
> >>>>
> >>>> I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282
> >> (no
> >>>> corresponding PRs in the Calcite repo yet).
> >>>>
> >>>> The corresponding PRs in the Avatica repo are:
> >>>> - https://github.com/apache/calcite-avatica/pull/238
> >>>> - https://github.com/apache/calcite-avatica/pull/241
> >>>>
> >>>> As the issue will require changes to both Calcite and Avatica in a
> >>>> coordinated fashion, what do you guys think about releasing Avatica
> >>>> 1.25.0 first? I can be RM for the Avatica release.
> >>>>
> >>>> Mihai, can you please confirm if this approach works for you?
> >>>>
> >>>> Discussion for getting changes simultaneously into both Avatica and
> >>>> Calcite is here [2].
> >>>>
> >>>> Francis
> >>>>
> >>>> [1] https://github.com/apache/calcite/pull/3708
> >>>> [2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq
> >>>>
> >>>> On 13/03/2024 10:07 pm, Benchao Li wrote:
> >>>>> Thank you, Hongyu, for volunteering to be a release manager.
> >>>>>
> >>>>> What's worth to mention is that to be a release manager does not
> >>>>> require PMC membership nor being a committer, and it is a good chance
> >>>>> to 

Re: [DISCUSS] Towards Calcite 1.37.0

[Francis Chuang]

+1 I think that's a good idea and will help clear some of the PR backlog.

On 9/04/2024 7:47 am, Sergey Nuyanzin wrote:

I think it would would make sense if they are already ready to be merged
Thanks for the suggestion

what do you think if we reserve about 2-3 days for this activity?
I would also encourage committers to merge such bug fixes if any



On Mon, Apr 8, 2024 at 11:36 PM Mihai Budiu  wrote:


Can we do another quick pass over the open PRs, or is it too late?
Since we started the process a bunch of bug fixes were submitted, and some
of them may be easy to merge.

Mihai

From: Sergey Nuyanzin 
Sent: Monday, April 8, 2024 2:32 PM
To: dev@calcite.apache.org 
Subject: Re: [DISCUSS] Towards Calcite 1.37.0

Upgrade of Avatica is done at CALCITE-6356 [1], thanks a lot for review
You can go forward with PRs if there still any

If there is no objections  I'm going to start steps to prepare and create
an RC tomorrow

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

On Mon, Apr 8, 2024 at 8:14 PM Mihai Budiu  wrote:


Hello,

I am assuming that (one of) the next steps towards 1.37 will be a PR

which

upgrades Avatica to 1.25.
Is anyone working on that?
After that is merged I plan to merge two PRs which re-enable the tests

that

were disabled temporarily.

Thank you,
Mihai


On Mon, Mar 18, 2024 at 9:48 AM Mihai Budiu  wrote:


This would be great, I am fixing two very basic bugs.
Was busy with some other stuff, so I didn't have time to figure out how

to

submit the PRs so that they pass, if anyone has more detailed

instructions

I would be very happy. Otherwise I will dig into it.

Mihai
--
*From:* Francis Chuang 
*Sent:* Sunday, March 17, 2024 2:44 PM
*To:* dev@calcite.apache.org 
*Subject:* Re: [DISCUSS] Towards Calcite 1.37.0

Hey everyone,

I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282

(no

corresponding PRs in the Calcite repo yet).

The corresponding PRs in the Avatica repo are:
- https://github.com/apache/calcite-avatica/pull/238
- https://github.com/apache/calcite-avatica/pull/241

As the issue will require changes to both Calcite and Avatica in a
coordinated fashion, what do you guys think about releasing Avatica
1.25.0 first? I can be RM for the Avatica release.

Mihai, can you please confirm if this approach works for you?

Discussion for getting changes simultaneously into both Avatica and
Calcite is here [2].

Francis

[1] https://github.com/apache/calcite/pull/3708
[2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq

On 13/03/2024 10:07 pm, Benchao Li wrote:

Thank you, Hongyu, for volunteering to be a release manager.

What's worth to mention is that to be a release manager does not
require PMC membership nor being a committer, and it is a good chance
to be involved in community activities apart from code/discussion,
which would be a good additional credit for being considered as
committer or PMC member candidate.

Hongyu Guo  于2024年3月13日周三 11:29写道：


I would like to take on the role of RM for one release

On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
alessandro.solima...@gmail.com> wrote:


Hey Sergey,
thanks for being the release manager for 1.37.0.

I have added fixVersion=1.37.0 to CALCITE-2040
<https://issues.apache.org/jira/browse/CALCITE-2040>, as its

associated PR

<https://github.com/apache/calcite/pull/3666> is in good shape

IMO,

and we

are trying to get it done shortly with Hongyu.

Best regards,
Alessandro

On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin 

wrote:



Updates about 1.37.0 releasing

According to our Jira dashboard [1] and Github [2], there
are 17 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.37.0

backlog and merge the PRs which are in a good state. I'd propose

to

aim for about 2 weeks to release 1.37.0, this will give us about
some time to clean up pending PRs for the next version. What do

you

think?


And contributors, if you have any work that is in good shape and

want

to be included in 1.37.0, please mark the fixVersion to 1.37.0,

this

will inform the release manager, and we'll try our best to get it

in.


A quick update on the current status for issues targeted 1.37.0
We need more reviewers for #2

#1. Issues already have reviewers, and seems promising to be

merged

shortly

https://issues.apache.org/jira/browse/CALCITE-6138
https://issues.apache.org/jira/browse/CALCITE-6015
https://issues.apache.org/jira/browse/CALCITE-6283
https://issues.apache.org/jira/browse/CALCITE-5607

   #2. Issues has been reviewed, and needs another reviewer
https://issues.apache.org/jira/browse/CALCITE-3522
https://issues.apache.org/jira/browse/CALCITE-6071
https://issues.apache.org/jira/browse/CALCITE-6210
https://issues.apache.org/jira/browse/CALCITE-6259
https://issues.apache.org/jira/browse/CALCITE-2067
https://issues.apache.org/jira/browse/

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

I think it would would make sense if they are already ready to be merged
Thanks for the suggestion

what do you think if we reserve about 2-3 days for this activity?
I would also encourage committers to merge such bug fixes if any



On Mon, Apr 8, 2024 at 11:36 PM Mihai Budiu  wrote:

> Can we do another quick pass over the open PRs, or is it too late?
> Since we started the process a bunch of bug fixes were submitted, and some
> of them may be easy to merge.
>
> Mihai
> 
> From: Sergey Nuyanzin 
> Sent: Monday, April 8, 2024 2:32 PM
> To: dev@calcite.apache.org 
> Subject: Re: [DISCUSS] Towards Calcite 1.37.0
>
> Upgrade of Avatica is done at CALCITE-6356 [1], thanks a lot for review
> You can go forward with PRs if there still any
>
> If there is no objections  I'm going to start steps to prepare and create
> an RC tomorrow
>
> [1] https://issues.apache.org/jira/browse/CALCITE-6356
>
> On Mon, Apr 8, 2024 at 8:14 PM Mihai Budiu  wrote:
>
> > Hello,
> >
> > I am assuming that (one of) the next steps towards 1.37 will be a PR
> which
> > upgrades Avatica to 1.25.
> > Is anyone working on that?
> > After that is merged I plan to merge two PRs which re-enable the tests
> that
> > were disabled temporarily.
> >
> > Thank you,
> > Mihai
> >
> >
> > On Mon, Mar 18, 2024 at 9:48 AM Mihai Budiu  wrote:
> >
> > > This would be great, I am fixing two very basic bugs.
> > > Was busy with some other stuff, so I didn't have time to figure out how
> > to
> > > submit the PRs so that they pass, if anyone has more detailed
> > instructions
> > > I would be very happy. Otherwise I will dig into it.
> > >
> > > Mihai
> > > --
> > > *From:* Francis Chuang 
> > > *Sent:* Sunday, March 17, 2024 2:44 PM
> > > *To:* dev@calcite.apache.org 
> > > *Subject:* Re: [DISCUSS] Towards Calcite 1.37.0
> > >
> > > Hey everyone,
> > >
> > > I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282
> (no
> > > corresponding PRs in the Calcite repo yet).
> > >
> > > The corresponding PRs in the Avatica repo are:
> > > - https://github.com/apache/calcite-avatica/pull/238
> > > - https://github.com/apache/calcite-avatica/pull/241
> > >
> > > As the issue will require changes to both Calcite and Avatica in a
> > > coordinated fashion, what do you guys think about releasing Avatica
> > > 1.25.0 first? I can be RM for the Avatica release.
> > >
> > > Mihai, can you please confirm if this approach works for you?
> > >
> > > Discussion for getting changes simultaneously into both Avatica and
> > > Calcite is here [2].
> > >
> > > Francis
> > >
> > > [1] https://github.com/apache/calcite/pull/3708
> > > [2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq
> > >
> > > On 13/03/2024 10:07 pm, Benchao Li wrote:
> > > > Thank you, Hongyu, for volunteering to be a release manager.
> > > >
> > > > What's worth to mention is that to be a release manager does not
> > > > require PMC membership nor being a committer, and it is a good chance
> > > > to be involved in community activities apart from code/discussion,
> > > > which would be a good additional credit for being considered as
> > > > committer or PMC member candidate.
> > > >
> > > > Hongyu Guo  于2024年3月13日周三 11:29写道：
> > > >>
> > > >> I would like to take on the role of RM for one release
> > > >>
> > > >> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
> > > >> alessandro.solima...@gmail.com> wrote:
> > > >>
> > > >>> Hey Sergey,
> > > >>> thanks for being the release manager for 1.37.0.
> > > >>>
> > > >>> I have added fixVersion=1.37.0 to CALCITE-2040
> > > >>> <https://issues.apache.org/jira/browse/CALCITE-2040>, as its
> > > associated PR
> > > >>> <https://github.com/apache/calcite/pull/3666> is in good shape
> IMO,
> > > and we
> > > >>> are trying to get it done shortly with Hongyu.
> > > >>>
> > > >>> Best regards,
> > > >>> Alessandro
> > > >>>
> > > >>> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin 
> > > wrote:
> > > >>>
> > &g

Re: [DISCUSS] Towards Calcite 1.37.0

[Mihai Budiu]

Can we do another quick pass over the open PRs, or is it too late?
Since we started the process a bunch of bug fixes were submitted, and some of 
them may be easy to merge.

Mihai

From: Sergey Nuyanzin 
Sent: Monday, April 8, 2024 2:32 PM
To: dev@calcite.apache.org 
Subject: Re: [DISCUSS] Towards Calcite 1.37.0

Upgrade of Avatica is done at CALCITE-6356 [1], thanks a lot for review
You can go forward with PRs if there still any

If there is no objections  I'm going to start steps to prepare and create
an RC tomorrow

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

On Mon, Apr 8, 2024 at 8:14 PM Mihai Budiu  wrote:

> Hello,
>
> I am assuming that (one of) the next steps towards 1.37 will be a PR which
> upgrades Avatica to 1.25.
> Is anyone working on that?
> After that is merged I plan to merge two PRs which re-enable the tests that
> were disabled temporarily.
>
> Thank you,
> Mihai
>
>
> On Mon, Mar 18, 2024 at 9:48 AM Mihai Budiu  wrote:
>
> > This would be great, I am fixing two very basic bugs.
> > Was busy with some other stuff, so I didn't have time to figure out how
> to
> > submit the PRs so that they pass, if anyone has more detailed
> instructions
> > I would be very happy. Otherwise I will dig into it.
> >
> > Mihai
> > --
> > *From:* Francis Chuang 
> > *Sent:* Sunday, March 17, 2024 2:44 PM
> > *To:* dev@calcite.apache.org 
> > *Subject:* Re: [DISCUSS] Towards Calcite 1.37.0
> >
> > Hey everyone,
> >
> > I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282 (no
> > corresponding PRs in the Calcite repo yet).
> >
> > The corresponding PRs in the Avatica repo are:
> > - https://github.com/apache/calcite-avatica/pull/238
> > - https://github.com/apache/calcite-avatica/pull/241
> >
> > As the issue will require changes to both Calcite and Avatica in a
> > coordinated fashion, what do you guys think about releasing Avatica
> > 1.25.0 first? I can be RM for the Avatica release.
> >
> > Mihai, can you please confirm if this approach works for you?
> >
> > Discussion for getting changes simultaneously into both Avatica and
> > Calcite is here [2].
> >
> > Francis
> >
> > [1] https://github.com/apache/calcite/pull/3708
> > [2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq
> >
> > On 13/03/2024 10:07 pm, Benchao Li wrote:
> > > Thank you, Hongyu, for volunteering to be a release manager.
> > >
> > > What's worth to mention is that to be a release manager does not
> > > require PMC membership nor being a committer, and it is a good chance
> > > to be involved in community activities apart from code/discussion,
> > > which would be a good additional credit for being considered as
> > > committer or PMC member candidate.
> > >
> > > Hongyu Guo  于2024年3月13日周三 11:29写道：
> > >>
> > >> I would like to take on the role of RM for one release
> > >>
> > >> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
> > >> alessandro.solima...@gmail.com> wrote:
> > >>
> > >>> Hey Sergey,
> > >>> thanks for being the release manager for 1.37.0.
> > >>>
> > >>> I have added fixVersion=1.37.0 to CALCITE-2040
> > >>> <https://issues.apache.org/jira/browse/CALCITE-2040>, as its
> > associated PR
> > >>> <https://github.com/apache/calcite/pull/3666> is in good shape IMO,
> > and we
> > >>> are trying to get it done shortly with Hongyu.
> > >>>
> > >>> Best regards,
> > >>> Alessandro
> > >>>
> > >>> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin 
> > wrote:
> > >>>
> > >>>> Updates about 1.37.0 releasing
> > >>>>
> > >>>> According to our Jira dashboard [1] and Github [2], there
> > >>>> are 17 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.37.0
> > >>>> backlog and merge the PRs which are in a good state. I'd propose to
> > >>>> aim for about 2 weeks to release 1.37.0, this will give us about
> > >>>> some time to clean up pending PRs for the next version. What do you
> > >>> think?
> > >>>>
> > >>>> And contributors, if you have any work that is in good shape and
> want
> > >>>> to

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

Upgrade of Avatica is done at CALCITE-6356 [1], thanks a lot for review
You can go forward with PRs if there still any

If there is no objections  I'm going to start steps to prepare and create
an RC tomorrow

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

On Mon, Apr 8, 2024 at 8:14 PM Mihai Budiu  wrote:

> Hello,
>
> I am assuming that (one of) the next steps towards 1.37 will be a PR which
> upgrades Avatica to 1.25.
> Is anyone working on that?
> After that is merged I plan to merge two PRs which re-enable the tests that
> were disabled temporarily.
>
> Thank you,
> Mihai
>
>
> On Mon, Mar 18, 2024 at 9:48 AM Mihai Budiu  wrote:
>
> > This would be great, I am fixing two very basic bugs.
> > Was busy with some other stuff, so I didn't have time to figure out how
> to
> > submit the PRs so that they pass, if anyone has more detailed
> instructions
> > I would be very happy. Otherwise I will dig into it.
> >
> > Mihai
> > --
> > *From:* Francis Chuang 
> > *Sent:* Sunday, March 17, 2024 2:44 PM
> > *To:* dev@calcite.apache.org 
> > *Subject:* Re: [DISCUSS] Towards Calcite 1.37.0
> >
> > Hey everyone,
> >
> > I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282 (no
> > corresponding PRs in the Calcite repo yet).
> >
> > The corresponding PRs in the Avatica repo are:
> > - https://github.com/apache/calcite-avatica/pull/238
> > - https://github.com/apache/calcite-avatica/pull/241
> >
> > As the issue will require changes to both Calcite and Avatica in a
> > coordinated fashion, what do you guys think about releasing Avatica
> > 1.25.0 first? I can be RM for the Avatica release.
> >
> > Mihai, can you please confirm if this approach works for you?
> >
> > Discussion for getting changes simultaneously into both Avatica and
> > Calcite is here [2].
> >
> > Francis
> >
> > [1] https://github.com/apache/calcite/pull/3708
> > [2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq
> >
> > On 13/03/2024 10:07 pm, Benchao Li wrote:
> > > Thank you, Hongyu, for volunteering to be a release manager.
> > >
> > > What's worth to mention is that to be a release manager does not
> > > require PMC membership nor being a committer, and it is a good chance
> > > to be involved in community activities apart from code/discussion,
> > > which would be a good additional credit for being considered as
> > > committer or PMC member candidate.
> > >
> > > Hongyu Guo  于2024年3月13日周三 11:29写道：
> > >>
> > >> I would like to take on the role of RM for one release
> > >>
> > >> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
> > >> alessandro.solima...@gmail.com> wrote:
> > >>
> > >>> Hey Sergey,
> > >>> thanks for being the release manager for 1.37.0.
> > >>>
> > >>> I have added fixVersion=1.37.0 to CALCITE-2040
> > >>> <https://issues.apache.org/jira/browse/CALCITE-2040>, as its
> > associated PR
> > >>> <https://github.com/apache/calcite/pull/3666> is in good shape IMO,
> > and we
> > >>> are trying to get it done shortly with Hongyu.
> > >>>
> > >>> Best regards,
> > >>> Alessandro
> > >>>
> > >>> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin 
> > wrote:
> > >>>
> > >>>> Updates about 1.37.0 releasing
> > >>>>
> > >>>> According to our Jira dashboard [1] and Github [2], there
> > >>>> are 17 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.37.0
> > >>>> backlog and merge the PRs which are in a good state. I'd propose to
> > >>>> aim for about 2 weeks to release 1.37.0, this will give us about
> > >>>> some time to clean up pending PRs for the next version. What do you
> > >>> think?
> > >>>>
> > >>>> And contributors, if you have any work that is in good shape and
> want
> > >>>> to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
> > >>>> will inform the release manager, and we'll try our best to get it
> in.
> > >>>>
> > >>>> A quick update on the current status for issues targeted 1.37.0
> > >>>> We need mor

Re: [DISCUSS] Towards Calcite 1.37.0

[Mihai Budiu]

Hello,

I am assuming that (one of) the next steps towards 1.37 will be a PR which
upgrades Avatica to 1.25.
Is anyone working on that?
After that is merged I plan to merge two PRs which re-enable the tests that
were disabled temporarily.

Thank you,
Mihai


On Mon, Mar 18, 2024 at 9:48 AM Mihai Budiu  wrote:

> This would be great, I am fixing two very basic bugs.
> Was busy with some other stuff, so I didn't have time to figure out how to
> submit the PRs so that they pass, if anyone has more detailed instructions
> I would be very happy. Otherwise I will dig into it.
>
> Mihai
> --
> *From:* Francis Chuang 
> *Sent:* Sunday, March 17, 2024 2:44 PM
> *To:* dev@calcite.apache.org 
> *Subject:* Re: [DISCUSS] Towards Calcite 1.37.0
>
> Hey everyone,
>
> I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282 (no
> corresponding PRs in the Calcite repo yet).
>
> The corresponding PRs in the Avatica repo are:
> - https://github.com/apache/calcite-avatica/pull/238
> - https://github.com/apache/calcite-avatica/pull/241
>
> As the issue will require changes to both Calcite and Avatica in a
> coordinated fashion, what do you guys think about releasing Avatica
> 1.25.0 first? I can be RM for the Avatica release.
>
> Mihai, can you please confirm if this approach works for you?
>
> Discussion for getting changes simultaneously into both Avatica and
> Calcite is here [2].
>
> Francis
>
> [1] https://github.com/apache/calcite/pull/3708
> [2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq
>
> On 13/03/2024 10:07 pm, Benchao Li wrote:
> > Thank you, Hongyu, for volunteering to be a release manager.
> >
> > What's worth to mention is that to be a release manager does not
> > require PMC membership nor being a committer, and it is a good chance
> > to be involved in community activities apart from code/discussion,
> > which would be a good additional credit for being considered as
> > committer or PMC member candidate.
> >
> > Hongyu Guo  于2024年3月13日周三 11:29写道：
> >>
> >> I would like to take on the role of RM for one release
> >>
> >> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
> >> alessandro.solima...@gmail.com> wrote:
> >>
> >>> Hey Sergey,
> >>> thanks for being the release manager for 1.37.0.
> >>>
> >>> I have added fixVersion=1.37.0 to CALCITE-2040
> >>> <https://issues.apache.org/jira/browse/CALCITE-2040>, as its
> associated PR
> >>> <https://github.com/apache/calcite/pull/3666> is in good shape IMO,
> and we
> >>> are trying to get it done shortly with Hongyu.
> >>>
> >>> Best regards,
> >>> Alessandro
> >>>
> >>> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin 
> wrote:
> >>>
> >>>> Updates about 1.37.0 releasing
> >>>>
> >>>> According to our Jira dashboard [1] and Github [2], there
> >>>> are 17 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.37.0
> >>>> backlog and merge the PRs which are in a good state. I'd propose to
> >>>> aim for about 2 weeks to release 1.37.0, this will give us about
> >>>> some time to clean up pending PRs for the next version. What do you
> >>> think?
> >>>>
> >>>> And contributors, if you have any work that is in good shape and want
> >>>> to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
> >>>> will inform the release manager, and we'll try our best to get it in.
> >>>>
> >>>> A quick update on the current status for issues targeted 1.37.0
> >>>> We need more reviewers for #2
> >>>>
> >>>> #1. Issues already have reviewers, and seems promising to be merged
> >>> shortly
> >>>> https://issues.apache.org/jira/browse/CALCITE-6138
> >>>> https://issues.apache.org/jira/browse/CALCITE-6015
> >>>> https://issues.apache.org/jira/browse/CALCITE-6283
> >>>> https://issues.apache.org/jira/browse/CALCITE-5607
> >>>>
> >>>>   #2. Issues has been reviewed, and needs another reviewer
> >>>> https://issues.apache.org/jira/browse/CALCITE-3522
> >>>> https://issues.apache.org/jira/browse/CALCITE-6071
> >>>> https://issues.apache.org/jira/browse/CALCITE-6210
> >>>> https://issues.apache.org/jira/browse/CALCIT

Re: [DISCUSS] Towards Calcite 1.37.0

[Jing Zhang]

Thanks Benchao for driving the discussion.

I would like to be release manager for 1.39.0 version.
Besides, I could help to review some open pull requests.

--

Best,
Jing Zhang

James Duong  于2024年3月19日周二 01:14写道：

> I’ll help take a look at some of the open Avatica and Calcite PRs.
>
> From: Mihai Budiu 
> Date: Monday, March 18, 2024 at 9:48 AM
> To: dev@calcite.apache.org 
> Subject: Re: [DISCUSS] Towards Calcite 1.37.0
> This would be great, I am fixing two very basic bugs.
> Was busy with some other stuff, so I didn't have time to figure out how to
> submit the PRs so that they pass, if anyone has more detailed instructions
> I would be very happy. Otherwise I will dig into it.
>
> Mihai
> 
> From: Francis Chuang 
> Sent: Sunday, March 17, 2024 2:44 PM
> To: dev@calcite.apache.org 
> Subject: Re: [DISCUSS] Towards Calcite 1.37.0
>
> Hey everyone,
>
> I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282 (no
> corresponding PRs in the Calcite repo yet).
>
> The corresponding PRs in the Avatica repo are:
> - https://github.com/apache/calcite-avatica/pull/238
> - https://github.com/apache/calcite-avatica/pull/241
>
> As the issue will require changes to both Calcite and Avatica in a
> coordinated fashion, what do you guys think about releasing Avatica
> 1.25.0 first? I can be RM for the Avatica release.
>
> Mihai, can you please confirm if this approach works for you?
>
> Discussion for getting changes simultaneously into both Avatica and
> Calcite is here [2].
>
> Francis
>
> [1] https://github.com/apache/calcite/pull/3708
> [2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq
>
> On 13/03/2024 10:07 pm, Benchao Li wrote:
> > Thank you, Hongyu, for volunteering to be a release manager.
> >
> > What's worth to mention is that to be a release manager does not
> > require PMC membership nor being a committer, and it is a good chance
> > to be involved in community activities apart from code/discussion,
> > which would be a good additional credit for being considered as
> > committer or PMC member candidate.
> >
> > Hongyu Guo  于2024年3月13日周三 11:29写道：
> >>
> >> I would like to take on the role of RM for one release
> >>
> >> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
> >> alessandro.solima...@gmail.com> wrote:
> >>
> >>> Hey Sergey,
> >>> thanks for being the release manager for 1.37.0.
> >>>
> >>> I have added fixVersion=1.37.0 to CALCITE-2040
> >>> <https://issues.apache.org/jira/browse/CALCITE-2040>, as its
> associated PR
> >>> <https://github.com/apache/calcite/pull/3666> is in good shape IMO,
> and we
> >>> are trying to get it done shortly with Hongyu.
> >>>
> >>> Best regards,
> >>> Alessandro
> >>>
> >>> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin 
> wrote:
> >>>
> >>>> Updates about 1.37.0 releasing
> >>>>
> >>>> According to our Jira dashboard [1] and Github [2], there
> >>>> are 17 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.37.0
> >>>> backlog and merge the PRs which are in a good state. I'd propose to
> >>>> aim for about 2 weeks to release 1.37.0, this will give us about
> >>>> some time to clean up pending PRs for the next version. What do you
> >>> think?
> >>>>
> >>>> And contributors, if you have any work that is in good shape and want
> >>>> to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
> >>>> will inform the release manager, and we'll try our best to get it in.
> >>>>
> >>>> A quick update on the current status for issues targeted 1.37.0
> >>>> We need more reviewers for #2
> >>>>
> >>>> #1. Issues already have reviewers, and seems promising to be merged
> >>> shortly
> >>>> https://issues.apache.org/jira/browse/CALCITE-6138
> >>>> https://issues.apache.org/jira/browse/CALCITE-6015
> >>>> https://issues.apache.org/jira/browse/CALCITE-6283
> >>>> https://issues.apache.org/jira/browse/CALCITE-5607
> >>>>
> >>>>   #2. Issues has been reviewed, and needs another reviewer
> >>>> https://issues.apache.org/jira/browse/CALCITE-3522
> >>>> https://issues.apache.org/jira/browse/CALCITE-6071
> >>>> 

Re: [DISCUSS] Towards Calcite 1.37.0

[James Duong]

I’ll help take a look at some of the open Avatica and Calcite PRs.

From: Mihai Budiu 
Date: Monday, March 18, 2024 at 9:48 AM
To: dev@calcite.apache.org 
Subject: Re: [DISCUSS] Towards Calcite 1.37.0
This would be great, I am fixing two very basic bugs.
Was busy with some other stuff, so I didn't have time to figure out how to 
submit the PRs so that they pass, if anyone has more detailed instructions I 
would be very happy. Otherwise I will dig into it.

Mihai

From: Francis Chuang 
Sent: Sunday, March 17, 2024 2:44 PM
To: dev@calcite.apache.org 
Subject: Re: [DISCUSS] Towards Calcite 1.37.0

Hey everyone,

I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282 (no
corresponding PRs in the Calcite repo yet).

The corresponding PRs in the Avatica repo are:
- https://github.com/apache/calcite-avatica/pull/238
- https://github.com/apache/calcite-avatica/pull/241

As the issue will require changes to both Calcite and Avatica in a
coordinated fashion, what do you guys think about releasing Avatica
1.25.0 first? I can be RM for the Avatica release.

Mihai, can you please confirm if this approach works for you?

Discussion for getting changes simultaneously into both Avatica and
Calcite is here [2].

Francis

[1] https://github.com/apache/calcite/pull/3708
[2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq

On 13/03/2024 10:07 pm, Benchao Li wrote:
> Thank you, Hongyu, for volunteering to be a release manager.
>
> What's worth to mention is that to be a release manager does not
> require PMC membership nor being a committer, and it is a good chance
> to be involved in community activities apart from code/discussion,
> which would be a good additional credit for being considered as
> committer or PMC member candidate.
>
> Hongyu Guo  于2024年3月13日周三 11:29写道：
>>
>> I would like to take on the role of RM for one release
>>
>> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
>> alessandro.solima...@gmail.com> wrote:
>>
>>> Hey Sergey,
>>> thanks for being the release manager for 1.37.0.
>>>
>>> I have added fixVersion=1.37.0 to CALCITE-2040
>>> <https://issues.apache.org/jira/browse/CALCITE-2040>, as its associated PR
>>> <https://github.com/apache/calcite/pull/3666> is in good shape IMO, and we
>>> are trying to get it done shortly with Hongyu.
>>>
>>> Best regards,
>>> Alessandro
>>>
>>> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin  wrote:
>>>
>>>> Updates about 1.37.0 releasing
>>>>
>>>> According to our Jira dashboard [1] and Github [2], there
>>>> are 17 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.37.0
>>>> backlog and merge the PRs which are in a good state. I'd propose to
>>>> aim for about 2 weeks to release 1.37.0, this will give us about
>>>> some time to clean up pending PRs for the next version. What do you
>>> think?
>>>>
>>>> And contributors, if you have any work that is in good shape and want
>>>> to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
>>>> will inform the release manager, and we'll try our best to get it in.
>>>>
>>>> A quick update on the current status for issues targeted 1.37.0
>>>> We need more reviewers for #2
>>>>
>>>> #1. Issues already have reviewers, and seems promising to be merged
>>> shortly
>>>> https://issues.apache.org/jira/browse/CALCITE-6138
>>>> https://issues.apache.org/jira/browse/CALCITE-6015
>>>> https://issues.apache.org/jira/browse/CALCITE-6283
>>>> https://issues.apache.org/jira/browse/CALCITE-5607
>>>>
>>>>   #2. Issues has been reviewed, and needs another reviewer
>>>> https://issues.apache.org/jira/browse/CALCITE-3522
>>>> https://issues.apache.org/jira/browse/CALCITE-6071
>>>> https://issues.apache.org/jira/browse/CALCITE-6210
>>>> https://issues.apache.org/jira/browse/CALCITE-6259
>>>> https://issues.apache.org/jira/browse/CALCITE-2067
>>>> https://issues.apache.org/jira/browse/CALCITE-6226
>>>> https://issues.apache.org/jira/browse/CALCITE-6193
>>>>
>>>>
>>>> It could happen that I miss something, please let me know
>>>> if there is something with fixVersion 1.37.0 ready for review and not
>>>> mentioned here
>>>>
>>>> Also I created a JIRA issue for releasing 1.37.0
>>>> https://issues.apache.org/jira/browse/CALCITE-63

Re: [DISCUSS] Towards Calcite 1.37.0

[Mihai Budiu]

This would be great, I am fixing two very basic bugs.
Was busy with some other stuff, so I didn't have time to figure out how to 
submit the PRs so that they pass, if anyone has more detailed instructions I 
would be very happy. Otherwise I will dig into it.

Mihai

From: Francis Chuang 
Sent: Sunday, March 17, 2024 2:44 PM
To: dev@calcite.apache.org 
Subject: Re: [DISCUSS] Towards Calcite 1.37.0

Hey everyone,

I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282 (no
corresponding PRs in the Calcite repo yet).

The corresponding PRs in the Avatica repo are:
- https://github.com/apache/calcite-avatica/pull/238
- https://github.com/apache/calcite-avatica/pull/241

As the issue will require changes to both Calcite and Avatica in a
coordinated fashion, what do you guys think about releasing Avatica
1.25.0 first? I can be RM for the Avatica release.

Mihai, can you please confirm if this approach works for you?

Discussion for getting changes simultaneously into both Avatica and
Calcite is here [2].

Francis

[1] https://github.com/apache/calcite/pull/3708
[2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq

On 13/03/2024 10:07 pm, Benchao Li wrote:
> Thank you, Hongyu, for volunteering to be a release manager.
>
> What's worth to mention is that to be a release manager does not
> require PMC membership nor being a committer, and it is a good chance
> to be involved in community activities apart from code/discussion,
> which would be a good additional credit for being considered as
> committer or PMC member candidate.
>
> Hongyu Guo  于2024年3月13日周三 11:29写道：
>>
>> I would like to take on the role of RM for one release
>>
>> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
>> alessandro.solima...@gmail.com> wrote:
>>
>>> Hey Sergey,
>>> thanks for being the release manager for 1.37.0.
>>>
>>> I have added fixVersion=1.37.0 to CALCITE-2040
>>> <https://issues.apache.org/jira/browse/CALCITE-2040>, as its associated PR
>>> <https://github.com/apache/calcite/pull/3666> is in good shape IMO, and we
>>> are trying to get it done shortly with Hongyu.
>>>
>>> Best regards,
>>> Alessandro
>>>
>>> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin  wrote:
>>>
>>>> Updates about 1.37.0 releasing
>>>>
>>>> According to our Jira dashboard [1] and Github [2], there
>>>> are 17 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.37.0
>>>> backlog and merge the PRs which are in a good state. I'd propose to
>>>> aim for about 2 weeks to release 1.37.0, this will give us about
>>>> some time to clean up pending PRs for the next version. What do you
>>> think?
>>>>
>>>> And contributors, if you have any work that is in good shape and want
>>>> to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
>>>> will inform the release manager, and we'll try our best to get it in.
>>>>
>>>> A quick update on the current status for issues targeted 1.37.0
>>>> We need more reviewers for #2
>>>>
>>>> #1. Issues already have reviewers, and seems promising to be merged
>>> shortly
>>>> https://issues.apache.org/jira/browse/CALCITE-6138
>>>> https://issues.apache.org/jira/browse/CALCITE-6015
>>>> https://issues.apache.org/jira/browse/CALCITE-6283
>>>> https://issues.apache.org/jira/browse/CALCITE-5607
>>>>
>>>>   #2. Issues has been reviewed, and needs another reviewer
>>>> https://issues.apache.org/jira/browse/CALCITE-3522
>>>> https://issues.apache.org/jira/browse/CALCITE-6071
>>>> https://issues.apache.org/jira/browse/CALCITE-6210
>>>> https://issues.apache.org/jira/browse/CALCITE-6259
>>>> https://issues.apache.org/jira/browse/CALCITE-2067
>>>> https://issues.apache.org/jira/browse/CALCITE-6226
>>>> https://issues.apache.org/jira/browse/CALCITE-6193
>>>>
>>>>
>>>> It could happen that I miss something, please let me know
>>>> if there is something with fixVersion 1.37.0 ready for review and not
>>>> mentioned here
>>>>
>>>> Also I created a JIRA issue for releasing 1.37.0
>>>> https://issues.apache.org/jira/browse/CALCITE-6302
>>>>
>>>> [1]
>>>>
>>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>>>> [2] https://github.com/apache/calcite/

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

Hi Francis

thanks for letting know

I think it would makes sense to apply this changes to Avatica and then to
Calcite


On Mon, Mar 18, 2024 at 8:59 AM Xiong Duan  wrote:

> +1 It is a good time to release a new version.
>
> Francis Chuang  于2024年3月18日周一 05:44写道：
> >
> > Hey everyone,
> >
> > I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282 (no
> > corresponding PRs in the Calcite repo yet).
> >
> > The corresponding PRs in the Avatica repo are:
> > - https://github.com/apache/calcite-avatica/pull/238
> > - https://github.com/apache/calcite-avatica/pull/241
> >
> > As the issue will require changes to both Calcite and Avatica in a
> > coordinated fashion, what do you guys think about releasing Avatica
> > 1.25.0 first? I can be RM for the Avatica release.
> >
> > Mihai, can you please confirm if this approach works for you?
> >
> > Discussion for getting changes simultaneously into both Avatica and
> > Calcite is here [2].
> >
> > Francis
> >
> > [1] https://github.com/apache/calcite/pull/3708
> > [2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq
> >
> > On 13/03/2024 10:07 pm, Benchao Li wrote:
> > > Thank you, Hongyu, for volunteering to be a release manager.
> > >
> > > What's worth to mention is that to be a release manager does not
> > > require PMC membership nor being a committer, and it is a good chance
> > > to be involved in community activities apart from code/discussion,
> > > which would be a good additional credit for being considered as
> > > committer or PMC member candidate.
> > >
> > > Hongyu Guo  于2024年3月13日周三 11:29写道：
> > >>
> > >> I would like to take on the role of RM for one release
> > >>
> > >> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
> > >> alessandro.solima...@gmail.com> wrote:
> > >>
> > >>> Hey Sergey,
> > >>> thanks for being the release manager for 1.37.0.
> > >>>
> > >>> I have added fixVersion=1.37.0 to CALCITE-2040
> > >>> , as its
> associated PR
> > >>>  is in good shape IMO,
> and we
> > >>> are trying to get it done shortly with Hongyu.
> > >>>
> > >>> Best regards,
> > >>> Alessandro
> > >>>
> > >>> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin 
> wrote:
> > >>>
> >  Updates about 1.37.0 releasing
> > 
> >  According to our Jira dashboard [1] and Github [2], there
> >  are 17 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.37.0
> >  backlog and merge the PRs which are in a good state. I'd propose to
> >  aim for about 2 weeks to release 1.37.0, this will give us about
> >  some time to clean up pending PRs for the next version. What do you
> > >>> think?
> > 
> >  And contributors, if you have any work that is in good shape and
> want
> >  to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
> >  will inform the release manager, and we'll try our best to get it
> in.
> > 
> >  A quick update on the current status for issues targeted 1.37.0
> >  We need more reviewers for #2
> > 
> >  #1. Issues already have reviewers, and seems promising to be merged
> > >>> shortly
> >  https://issues.apache.org/jira/browse/CALCITE-6138
> >  https://issues.apache.org/jira/browse/CALCITE-6015
> >  https://issues.apache.org/jira/browse/CALCITE-6283
> >  https://issues.apache.org/jira/browse/CALCITE-5607
> > 
> >    #2. Issues has been reviewed, and needs another reviewer
> >  https://issues.apache.org/jira/browse/CALCITE-3522
> >  https://issues.apache.org/jira/browse/CALCITE-6071
> >  https://issues.apache.org/jira/browse/CALCITE-6210
> >  https://issues.apache.org/jira/browse/CALCITE-6259
> >  https://issues.apache.org/jira/browse/CALCITE-2067
> >  https://issues.apache.org/jira/browse/CALCITE-6226
> >  https://issues.apache.org/jira/browse/CALCITE-6193
> > 
> > 
> >  It could happen that I miss something, please let me know
> >  if there is something with fixVersion 1.37.0 ready for review and
> not
> >  mentioned here
> > 
> >  Also I created a JIRA issue for releasing 1.37.0
> >  https://issues.apache.org/jira/browse/CALCITE-6302
> > 
> >  [1]
> > 
> > >>>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> >  [2] https://github.com/apache/calcite/pulls
> > 
> >  On Fri, Feb 23, 2024 at 9:24 PM Julian Hyde  >
> >  wrote:
> > 
> > > +1 for a release.
> > >
> > > Our users rely on a regular cadence of releases. If someone
> submits a
> > > patch and doesn’t see it in a release until 6 months later (or it
> sits
> > > un-reviewed) they will be less inclined to submit a patch.
> > >
> > > Yeah, I know Open Source Doesn’t Require Providing Builds [1] but
> it
> >  makes
> > > everyone’s life easier.

Re: [DISCUSS] Towards Calcite 1.37.0

[Xiong Duan]

+1 It is a good time to release a new version.

Francis Chuang  于2024年3月18日周一 05:44写道：
>
> Hey everyone,
>
> I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282 (no
> corresponding PRs in the Calcite repo yet).
>
> The corresponding PRs in the Avatica repo are:
> - https://github.com/apache/calcite-avatica/pull/238
> - https://github.com/apache/calcite-avatica/pull/241
>
> As the issue will require changes to both Calcite and Avatica in a
> coordinated fashion, what do you guys think about releasing Avatica
> 1.25.0 first? I can be RM for the Avatica release.
>
> Mihai, can you please confirm if this approach works for you?
>
> Discussion for getting changes simultaneously into both Avatica and
> Calcite is here [2].
>
> Francis
>
> [1] https://github.com/apache/calcite/pull/3708
> [2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq
>
> On 13/03/2024 10:07 pm, Benchao Li wrote:
> > Thank you, Hongyu, for volunteering to be a release manager.
> >
> > What's worth to mention is that to be a release manager does not
> > require PMC membership nor being a committer, and it is a good chance
> > to be involved in community activities apart from code/discussion,
> > which would be a good additional credit for being considered as
> > committer or PMC member candidate.
> >
> > Hongyu Guo  于2024年3月13日周三 11:29写道：
> >>
> >> I would like to take on the role of RM for one release
> >>
> >> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
> >> alessandro.solima...@gmail.com> wrote:
> >>
> >>> Hey Sergey,
> >>> thanks for being the release manager for 1.37.0.
> >>>
> >>> I have added fixVersion=1.37.0 to CALCITE-2040
> >>> , as its associated PR
> >>>  is in good shape IMO, and we
> >>> are trying to get it done shortly with Hongyu.
> >>>
> >>> Best regards,
> >>> Alessandro
> >>>
> >>> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin  wrote:
> >>>
>  Updates about 1.37.0 releasing
> 
>  According to our Jira dashboard [1] and Github [2], there
>  are 17 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.37.0
>  backlog and merge the PRs which are in a good state. I'd propose to
>  aim for about 2 weeks to release 1.37.0, this will give us about
>  some time to clean up pending PRs for the next version. What do you
> >>> think?
> 
>  And contributors, if you have any work that is in good shape and want
>  to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
>  will inform the release manager, and we'll try our best to get it in.
> 
>  A quick update on the current status for issues targeted 1.37.0
>  We need more reviewers for #2
> 
>  #1. Issues already have reviewers, and seems promising to be merged
> >>> shortly
>  https://issues.apache.org/jira/browse/CALCITE-6138
>  https://issues.apache.org/jira/browse/CALCITE-6015
>  https://issues.apache.org/jira/browse/CALCITE-6283
>  https://issues.apache.org/jira/browse/CALCITE-5607
> 
>    #2. Issues has been reviewed, and needs another reviewer
>  https://issues.apache.org/jira/browse/CALCITE-3522
>  https://issues.apache.org/jira/browse/CALCITE-6071
>  https://issues.apache.org/jira/browse/CALCITE-6210
>  https://issues.apache.org/jira/browse/CALCITE-6259
>  https://issues.apache.org/jira/browse/CALCITE-2067
>  https://issues.apache.org/jira/browse/CALCITE-6226
>  https://issues.apache.org/jira/browse/CALCITE-6193
> 
> 
>  It could happen that I miss something, please let me know
>  if there is something with fixVersion 1.37.0 ready for review and not
>  mentioned here
> 
>  Also I created a JIRA issue for releasing 1.37.0
>  https://issues.apache.org/jira/browse/CALCITE-6302
> 
>  [1]
> 
> >>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>  [2] https://github.com/apache/calcite/pulls
> 
>  On Fri, Feb 23, 2024 at 9:24 PM Julian Hyde 
>  wrote:
> 
> > +1 for a release.
> >
> > Our users rely on a regular cadence of releases. If someone submits a
> > patch and doesn’t see it in a release until 6 months later (or it sits
> > un-reviewed) they will be less inclined to submit a patch.
> >
> > Yeah, I know Open Source Doesn’t Require Providing Builds [1] but it
>  makes
> > everyone’s life easier.
> >
> > Julian
> >
> > [1] https://news.ycombinator.com/item?id=39094387
> >
> >
> >> On Feb 21, 2024, at 1:18 AM, Stamatis Zampetakis 
> > wrote:
> >>
> >> With so many commits it's definitely a good time to cut a new
> >>> release.
> >>
> >> I can be the RM for 1.39.0 or 1.40.0 depending on the timing.
> >>
> >> Best,
> >> Stamatis
> >>
> >> On Wed, 

Re: [DISCUSS] Towards Calcite 1.37.0

[Francis Chuang]

Hey everyone,

I just wanted to jump in regarding CALCITE-6248 [1] and CALCITE-6282 (no 
corresponding PRs in the Calcite repo yet).


The corresponding PRs in the Avatica repo are:
- https://github.com/apache/calcite-avatica/pull/238
- https://github.com/apache/calcite-avatica/pull/241

As the issue will require changes to both Calcite and Avatica in a 
coordinated fashion, what do you guys think about releasing Avatica 
1.25.0 first? I can be RM for the Avatica release.


Mihai, can you please confirm if this approach works for you?

Discussion for getting changes simultaneously into both Avatica and 
Calcite is here [2].


Francis

[1] https://github.com/apache/calcite/pull/3708
[2] https://lists.apache.org/thread/5w3ry3zbm7671ffp4pxh7lx6cgc5r3tq

On 13/03/2024 10:07 pm, Benchao Li wrote:

Thank you, Hongyu, for volunteering to be a release manager.

What's worth to mention is that to be a release manager does not
require PMC membership nor being a committer, and it is a good chance
to be involved in community activities apart from code/discussion,
which would be a good additional credit for being considered as
committer or PMC member candidate.

Hongyu Guo  于2024年3月13日周三 11:29写道：


I would like to take on the role of RM for one release

On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
alessandro.solima...@gmail.com> wrote:


Hey Sergey,
thanks for being the release manager for 1.37.0.

I have added fixVersion=1.37.0 to CALCITE-2040
, as its associated PR
 is in good shape IMO, and we
are trying to get it done shortly with Hongyu.

Best regards,
Alessandro

On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin  wrote:


Updates about 1.37.0 releasing

According to our Jira dashboard [1] and Github [2], there
are 17 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.37.0
backlog and merge the PRs which are in a good state. I'd propose to
aim for about 2 weeks to release 1.37.0, this will give us about
some time to clean up pending PRs for the next version. What do you

think?


And contributors, if you have any work that is in good shape and want
to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
will inform the release manager, and we'll try our best to get it in.

A quick update on the current status for issues targeted 1.37.0
We need more reviewers for #2

#1. Issues already have reviewers, and seems promising to be merged

shortly

https://issues.apache.org/jira/browse/CALCITE-6138
https://issues.apache.org/jira/browse/CALCITE-6015
https://issues.apache.org/jira/browse/CALCITE-6283
https://issues.apache.org/jira/browse/CALCITE-5607

  #2. Issues has been reviewed, and needs another reviewer
https://issues.apache.org/jira/browse/CALCITE-3522
https://issues.apache.org/jira/browse/CALCITE-6071
https://issues.apache.org/jira/browse/CALCITE-6210
https://issues.apache.org/jira/browse/CALCITE-6259
https://issues.apache.org/jira/browse/CALCITE-2067
https://issues.apache.org/jira/browse/CALCITE-6226
https://issues.apache.org/jira/browse/CALCITE-6193


It could happen that I miss something, please let me know
if there is something with fixVersion 1.37.0 ready for review and not
mentioned here

Also I created a JIRA issue for releasing 1.37.0
https://issues.apache.org/jira/browse/CALCITE-6302

[1]


https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950

[2] https://github.com/apache/calcite/pulls

On Fri, Feb 23, 2024 at 9:24 PM Julian Hyde 
wrote:


+1 for a release.

Our users rely on a regular cadence of releases. If someone submits a
patch and doesn’t see it in a release until 6 months later (or it sits
un-reviewed) they will be less inclined to submit a patch.

Yeah, I know Open Source Doesn’t Require Providing Builds [1] but it

makes

everyone’s life easier.

Julian

[1] https://news.ycombinator.com/item?id=39094387



On Feb 21, 2024, at 1:18 AM, Stamatis Zampetakis 

wrote:


With so many commits it's definitely a good time to cut a new

release.


I can be the RM for 1.39.0 or 1.40.0 depending on the timing.

Best,
Stamatis

On Wed, Feb 21, 2024 at 12:10 AM Sergey Nuyanzin <

snuyan...@gmail.com>

wrote:


Thanks for starting the discussion


@Sergey, are you still available for being the release manager for

1.37.0?


I think so, in theory I could start with some steps in one/two weeks

if

there is no objections



On Mon, Feb 19, 2024 at 12:29 PM Benchao Li 

wrote:



It's been a bit more than 3 months since our last release

(2023-11-10)

[1] and there are currently 100+ new commits in main branch. Per

our

tradition of producing one release every 2-3 months, I think it's

time

to consider for next release now.

According to [2], the following release managers would be:
- 1.37.0 Sergey Nuyanzin
- 1.38.0 Julian Hyde

@Sergey, are you still available for being the release manager for

1.37.0?

Re: [DISCUSS] Towards Calcite 1.37.0

[Benchao Li]

Thank you, Hongyu, for volunteering to be a release manager.

What's worth to mention is that to be a release manager does not
require PMC membership nor being a committer, and it is a good chance
to be involved in community activities apart from code/discussion,
which would be a good additional credit for being considered as
committer or PMC member candidate.

Hongyu Guo  于2024年3月13日周三 11:29写道：
>
> I would like to take on the role of RM for one release
>
> On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
> alessandro.solima...@gmail.com> wrote:
>
> > Hey Sergey,
> > thanks for being the release manager for 1.37.0.
> >
> > I have added fixVersion=1.37.0 to CALCITE-2040
> > , as its associated PR
> >  is in good shape IMO, and we
> > are trying to get it done shortly with Hongyu.
> >
> > Best regards,
> > Alessandro
> >
> > On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin  wrote:
> >
> > > Updates about 1.37.0 releasing
> > >
> > > According to our Jira dashboard [1] and Github [2], there
> > > are 17 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.37.0
> > > backlog and merge the PRs which are in a good state. I'd propose to
> > > aim for about 2 weeks to release 1.37.0, this will give us about
> > > some time to clean up pending PRs for the next version. What do you
> > think?
> > >
> > > And contributors, if you have any work that is in good shape and want
> > > to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
> > > will inform the release manager, and we'll try our best to get it in.
> > >
> > > A quick update on the current status for issues targeted 1.37.0
> > > We need more reviewers for #2
> > >
> > > #1. Issues already have reviewers, and seems promising to be merged
> > shortly
> > > https://issues.apache.org/jira/browse/CALCITE-6138
> > > https://issues.apache.org/jira/browse/CALCITE-6015
> > > https://issues.apache.org/jira/browse/CALCITE-6283
> > > https://issues.apache.org/jira/browse/CALCITE-5607
> > >
> > >  #2. Issues has been reviewed, and needs another reviewer
> > > https://issues.apache.org/jira/browse/CALCITE-3522
> > > https://issues.apache.org/jira/browse/CALCITE-6071
> > > https://issues.apache.org/jira/browse/CALCITE-6210
> > > https://issues.apache.org/jira/browse/CALCITE-6259
> > > https://issues.apache.org/jira/browse/CALCITE-2067
> > > https://issues.apache.org/jira/browse/CALCITE-6226
> > > https://issues.apache.org/jira/browse/CALCITE-6193
> > >
> > >
> > > It could happen that I miss something, please let me know
> > > if there is something with fixVersion 1.37.0 ready for review and not
> > > mentioned here
> > >
> > > Also I created a JIRA issue for releasing 1.37.0
> > > https://issues.apache.org/jira/browse/CALCITE-6302
> > >
> > > [1]
> > >
> > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > [2] https://github.com/apache/calcite/pulls
> > >
> > > On Fri, Feb 23, 2024 at 9:24 PM Julian Hyde 
> > > wrote:
> > >
> > > > +1 for a release.
> > > >
> > > > Our users rely on a regular cadence of releases. If someone submits a
> > > > patch and doesn’t see it in a release until 6 months later (or it sits
> > > > un-reviewed) they will be less inclined to submit a patch.
> > > >
> > > > Yeah, I know Open Source Doesn’t Require Providing Builds [1] but it
> > > makes
> > > > everyone’s life easier.
> > > >
> > > > Julian
> > > >
> > > > [1] https://news.ycombinator.com/item?id=39094387
> > > >
> > > >
> > > > > On Feb 21, 2024, at 1:18 AM, Stamatis Zampetakis 
> > > > wrote:
> > > > >
> > > > > With so many commits it's definitely a good time to cut a new
> > release.
> > > > >
> > > > > I can be the RM for 1.39.0 or 1.40.0 depending on the timing.
> > > > >
> > > > > Best,
> > > > > Stamatis
> > > > >
> > > > > On Wed, Feb 21, 2024 at 12:10 AM Sergey Nuyanzin <
> > snuyan...@gmail.com>
> > > > wrote:
> > > > >>
> > > > >> Thanks for starting the discussion
> > > > >>
> > > > >>> @Sergey, are you still available for being the release manager for
> > > > 1.37.0?
> > > > >>
> > > > >> I think so, in theory I could start with some steps in one/two weeks
> > > if
> > > > >> there is no objections
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Mon, Feb 19, 2024 at 12:29 PM Benchao Li 
> > > > wrote:
> > > > >>
> > > > >>> It's been a bit more than 3 months since our last release
> > > (2023-11-10)
> > > > >>> [1] and there are currently 100+ new commits in main branch. Per
> > our
> > > > >>> tradition of producing one release every 2-3 months, I think it's
> > > time
> > > > >>> to consider for next release now.
> > > > >>>
> > > > >>> According to [2], the following release managers would be:
> > > > >>> - 1.37.0 Sergey Nuyanzin
> > > > >>> - 1.38.0 Julian Hyde
> > > > >>>
> > > > >>> @Sergey, are you still available for being the release manager for
> 

Re: [DISCUSS] Towards Calcite 1.37.0

[Hongyu Guo]

I would like to take on the role of RM for one release

On Thu, Mar 7, 2024 at 2:58 AM Alessandro Solimando <
alessandro.solima...@gmail.com> wrote:

> Hey Sergey,
> thanks for being the release manager for 1.37.0.
>
> I have added fixVersion=1.37.0 to CALCITE-2040
> , as its associated PR
>  is in good shape IMO, and we
> are trying to get it done shortly with Hongyu.
>
> Best regards,
> Alessandro
>
> On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin  wrote:
>
> > Updates about 1.37.0 releasing
> >
> > According to our Jira dashboard [1] and Github [2], there
> > are 17 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.37.0
> > backlog and merge the PRs which are in a good state. I'd propose to
> > aim for about 2 weeks to release 1.37.0, this will give us about
> > some time to clean up pending PRs for the next version. What do you
> think?
> >
> > And contributors, if you have any work that is in good shape and want
> > to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
> > will inform the release manager, and we'll try our best to get it in.
> >
> > A quick update on the current status for issues targeted 1.37.0
> > We need more reviewers for #2
> >
> > #1. Issues already have reviewers, and seems promising to be merged
> shortly
> > https://issues.apache.org/jira/browse/CALCITE-6138
> > https://issues.apache.org/jira/browse/CALCITE-6015
> > https://issues.apache.org/jira/browse/CALCITE-6283
> > https://issues.apache.org/jira/browse/CALCITE-5607
> >
> >  #2. Issues has been reviewed, and needs another reviewer
> > https://issues.apache.org/jira/browse/CALCITE-3522
> > https://issues.apache.org/jira/browse/CALCITE-6071
> > https://issues.apache.org/jira/browse/CALCITE-6210
> > https://issues.apache.org/jira/browse/CALCITE-6259
> > https://issues.apache.org/jira/browse/CALCITE-2067
> > https://issues.apache.org/jira/browse/CALCITE-6226
> > https://issues.apache.org/jira/browse/CALCITE-6193
> >
> >
> > It could happen that I miss something, please let me know
> > if there is something with fixVersion 1.37.0 ready for review and not
> > mentioned here
> >
> > Also I created a JIRA issue for releasing 1.37.0
> > https://issues.apache.org/jira/browse/CALCITE-6302
> >
> > [1]
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > [2] https://github.com/apache/calcite/pulls
> >
> > On Fri, Feb 23, 2024 at 9:24 PM Julian Hyde 
> > wrote:
> >
> > > +1 for a release.
> > >
> > > Our users rely on a regular cadence of releases. If someone submits a
> > > patch and doesn’t see it in a release until 6 months later (or it sits
> > > un-reviewed) they will be less inclined to submit a patch.
> > >
> > > Yeah, I know Open Source Doesn’t Require Providing Builds [1] but it
> > makes
> > > everyone’s life easier.
> > >
> > > Julian
> > >
> > > [1] https://news.ycombinator.com/item?id=39094387
> > >
> > >
> > > > On Feb 21, 2024, at 1:18 AM, Stamatis Zampetakis 
> > > wrote:
> > > >
> > > > With so many commits it's definitely a good time to cut a new
> release.
> > > >
> > > > I can be the RM for 1.39.0 or 1.40.0 depending on the timing.
> > > >
> > > > Best,
> > > > Stamatis
> > > >
> > > > On Wed, Feb 21, 2024 at 12:10 AM Sergey Nuyanzin <
> snuyan...@gmail.com>
> > > wrote:
> > > >>
> > > >> Thanks for starting the discussion
> > > >>
> > > >>> @Sergey, are you still available for being the release manager for
> > > 1.37.0?
> > > >>
> > > >> I think so, in theory I could start with some steps in one/two weeks
> > if
> > > >> there is no objections
> > > >>
> > > >>
> > > >>
> > > >> On Mon, Feb 19, 2024 at 12:29 PM Benchao Li 
> > > wrote:
> > > >>
> > > >>> It's been a bit more than 3 months since our last release
> > (2023-11-10)
> > > >>> [1] and there are currently 100+ new commits in main branch. Per
> our
> > > >>> tradition of producing one release every 2-3 months, I think it's
> > time
> > > >>> to consider for next release now.
> > > >>>
> > > >>> According to [2], the following release managers would be:
> > > >>> - 1.37.0 Sergey Nuyanzin
> > > >>> - 1.38.0 Julian Hyde
> > > >>>
> > > >>> @Sergey, are you still available for being the release manager for
> > > 1.37.0?
> > > >>>
> > > >>> Besides, we need more volunteers for the next releases (version >=
> > > >>> 1.39.0), anyone who is interested in doing it can reply in this
> > > >>> thread.
> > > >>>
> > > >>> [1] https://calcite.apache.org/docs/history.html#v1-36-0
> > > >>> [4]
> https://lists.apache.org/thread/tm3t42qvpq3db24xtd2g468ofv83l6hk
> > > >>>
> > > >>>
> > > >>> --
> > > >>>
> > > >>> Best,
> > > >>> Benchao Li
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Sergey
> > >
> > >
> >
> > --
> > Best regards,
> > Sergey
> >
>

Re: [DISCUSS] Towards Calcite 1.37.0

[Alessandro Solimando]

Hey Sergey,
thanks for being the release manager for 1.37.0.

I have added fixVersion=1.37.0 to CALCITE-2040
, as its associated PR
 is in good shape IMO, and we
are trying to get it done shortly with Hongyu.

Best regards,
Alessandro

On Wed, 6 Mar 2024 at 16:49, Sergey Nuyanzin  wrote:

> Updates about 1.37.0 releasing
>
> According to our Jira dashboard [1] and Github [2], there
> are 17 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.37.0
> backlog and merge the PRs which are in a good state. I'd propose to
> aim for about 2 weeks to release 1.37.0, this will give us about
> some time to clean up pending PRs for the next version. What do you think?
>
> And contributors, if you have any work that is in good shape and want
> to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
> will inform the release manager, and we'll try our best to get it in.
>
> A quick update on the current status for issues targeted 1.37.0
> We need more reviewers for #2
>
> #1. Issues already have reviewers, and seems promising to be merged shortly
> https://issues.apache.org/jira/browse/CALCITE-6138
> https://issues.apache.org/jira/browse/CALCITE-6015
> https://issues.apache.org/jira/browse/CALCITE-6283
> https://issues.apache.org/jira/browse/CALCITE-5607
>
>  #2. Issues has been reviewed, and needs another reviewer
> https://issues.apache.org/jira/browse/CALCITE-3522
> https://issues.apache.org/jira/browse/CALCITE-6071
> https://issues.apache.org/jira/browse/CALCITE-6210
> https://issues.apache.org/jira/browse/CALCITE-6259
> https://issues.apache.org/jira/browse/CALCITE-2067
> https://issues.apache.org/jira/browse/CALCITE-6226
> https://issues.apache.org/jira/browse/CALCITE-6193
>
>
> It could happen that I miss something, please let me know
> if there is something with fixVersion 1.37.0 ready for review and not
> mentioned here
>
> Also I created a JIRA issue for releasing 1.37.0
> https://issues.apache.org/jira/browse/CALCITE-6302
>
> [1]
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> [2] https://github.com/apache/calcite/pulls
>
> On Fri, Feb 23, 2024 at 9:24 PM Julian Hyde 
> wrote:
>
> > +1 for a release.
> >
> > Our users rely on a regular cadence of releases. If someone submits a
> > patch and doesn’t see it in a release until 6 months later (or it sits
> > un-reviewed) they will be less inclined to submit a patch.
> >
> > Yeah, I know Open Source Doesn’t Require Providing Builds [1] but it
> makes
> > everyone’s life easier.
> >
> > Julian
> >
> > [1] https://news.ycombinator.com/item?id=39094387
> >
> >
> > > On Feb 21, 2024, at 1:18 AM, Stamatis Zampetakis 
> > wrote:
> > >
> > > With so many commits it's definitely a good time to cut a new release.
> > >
> > > I can be the RM for 1.39.0 or 1.40.0 depending on the timing.
> > >
> > > Best,
> > > Stamatis
> > >
> > > On Wed, Feb 21, 2024 at 12:10 AM Sergey Nuyanzin 
> > wrote:
> > >>
> > >> Thanks for starting the discussion
> > >>
> > >>> @Sergey, are you still available for being the release manager for
> > 1.37.0?
> > >>
> > >> I think so, in theory I could start with some steps in one/two weeks
> if
> > >> there is no objections
> > >>
> > >>
> > >>
> > >> On Mon, Feb 19, 2024 at 12:29 PM Benchao Li 
> > wrote:
> > >>
> > >>> It's been a bit more than 3 months since our last release
> (2023-11-10)
> > >>> [1] and there are currently 100+ new commits in main branch. Per our
> > >>> tradition of producing one release every 2-3 months, I think it's
> time
> > >>> to consider for next release now.
> > >>>
> > >>> According to [2], the following release managers would be:
> > >>> - 1.37.0 Sergey Nuyanzin
> > >>> - 1.38.0 Julian Hyde
> > >>>
> > >>> @Sergey, are you still available for being the release manager for
> > 1.37.0?
> > >>>
> > >>> Besides, we need more volunteers for the next releases (version >=
> > >>> 1.39.0), anyone who is interested in doing it can reply in this
> > >>> thread.
> > >>>
> > >>> [1] https://calcite.apache.org/docs/history.html#v1-36-0
> > >>> [4] https://lists.apache.org/thread/tm3t42qvpq3db24xtd2g468ofv83l6hk
> > >>>
> > >>>
> > >>> --
> > >>>
> > >>> Best,
> > >>> Benchao Li
> > >>>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >> Sergey
> >
> >
>
> --
> Best regards,
> Sergey
>

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

Updates about 1.37.0 releasing

According to our Jira dashboard [1] and Github [2], there
are 17 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.37.0
backlog and merge the PRs which are in a good state. I'd propose to
aim for about 2 weeks to release 1.37.0, this will give us about
some time to clean up pending PRs for the next version. What do you think?

And contributors, if you have any work that is in good shape and want
to be included in 1.37.0, please mark the fixVersion to 1.37.0, this
will inform the release manager, and we'll try our best to get it in.

A quick update on the current status for issues targeted 1.37.0
We need more reviewers for #2

#1. Issues already have reviewers, and seems promising to be merged shortly
https://issues.apache.org/jira/browse/CALCITE-6138
https://issues.apache.org/jira/browse/CALCITE-6015
https://issues.apache.org/jira/browse/CALCITE-6283
https://issues.apache.org/jira/browse/CALCITE-5607

 #2. Issues has been reviewed, and needs another reviewer
https://issues.apache.org/jira/browse/CALCITE-3522
https://issues.apache.org/jira/browse/CALCITE-6071
https://issues.apache.org/jira/browse/CALCITE-6210
https://issues.apache.org/jira/browse/CALCITE-6259
https://issues.apache.org/jira/browse/CALCITE-2067
https://issues.apache.org/jira/browse/CALCITE-6226
https://issues.apache.org/jira/browse/CALCITE-6193


It could happen that I miss something, please let me know
if there is something with fixVersion 1.37.0 ready for review and not
mentioned here

Also I created a JIRA issue for releasing 1.37.0
https://issues.apache.org/jira/browse/CALCITE-6302

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

On Fri, Feb 23, 2024 at 9:24 PM Julian Hyde  wrote:

> +1 for a release.
>
> Our users rely on a regular cadence of releases. If someone submits a
> patch and doesn’t see it in a release until 6 months later (or it sits
> un-reviewed) they will be less inclined to submit a patch.
>
> Yeah, I know Open Source Doesn’t Require Providing Builds [1] but it makes
> everyone’s life easier.
>
> Julian
>
> [1] https://news.ycombinator.com/item?id=39094387
>
>
> > On Feb 21, 2024, at 1:18 AM, Stamatis Zampetakis 
> wrote:
> >
> > With so many commits it's definitely a good time to cut a new release.
> >
> > I can be the RM for 1.39.0 or 1.40.0 depending on the timing.
> >
> > Best,
> > Stamatis
> >
> > On Wed, Feb 21, 2024 at 12:10 AM Sergey Nuyanzin 
> wrote:
> >>
> >> Thanks for starting the discussion
> >>
> >>> @Sergey, are you still available for being the release manager for
> 1.37.0?
> >>
> >> I think so, in theory I could start with some steps in one/two weeks if
> >> there is no objections
> >>
> >>
> >>
> >> On Mon, Feb 19, 2024 at 12:29 PM Benchao Li 
> wrote:
> >>
> >>> It's been a bit more than 3 months since our last release (2023-11-10)
> >>> [1] and there are currently 100+ new commits in main branch. Per our
> >>> tradition of producing one release every 2-3 months, I think it's time
> >>> to consider for next release now.
> >>>
> >>> According to [2], the following release managers would be:
> >>> - 1.37.0 Sergey Nuyanzin
> >>> - 1.38.0 Julian Hyde
> >>>
> >>> @Sergey, are you still available for being the release manager for
> 1.37.0?
> >>>
> >>> Besides, we need more volunteers for the next releases (version >=
> >>> 1.39.0), anyone who is interested in doing it can reply in this
> >>> thread.
> >>>
> >>> [1] https://calcite.apache.org/docs/history.html#v1-36-0
> >>> [4] https://lists.apache.org/thread/tm3t42qvpq3db24xtd2g468ofv83l6hk
> >>>
> >>>
> >>> --
> >>>
> >>> Best,
> >>> Benchao Li
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Sergey
>
>

-- 
Best regards,
Sergey

Re: [DISCUSS] Towards Calcite 1.37.0

[Julian Hyde]

+1 for a release.

Our users rely on a regular cadence of releases. If someone submits a patch and 
doesn’t see it in a release until 6 months later (or it sits un-reviewed) they 
will be less inclined to submit a patch.

Yeah, I know Open Source Doesn’t Require Providing Builds [1] but it makes 
everyone’s life easier.

Julian

[1] https://news.ycombinator.com/item?id=39094387


> On Feb 21, 2024, at 1:18 AM, Stamatis Zampetakis  wrote:
> 
> With so many commits it's definitely a good time to cut a new release.
> 
> I can be the RM for 1.39.0 or 1.40.0 depending on the timing.
> 
> Best,
> Stamatis
> 
> On Wed, Feb 21, 2024 at 12:10 AM Sergey Nuyanzin  wrote:
>> 
>> Thanks for starting the discussion
>> 
>>> @Sergey, are you still available for being the release manager for 1.37.0?
>> 
>> I think so, in theory I could start with some steps in one/two weeks if
>> there is no objections
>> 
>> 
>> 
>> On Mon, Feb 19, 2024 at 12:29 PM Benchao Li  wrote:
>> 
>>> It's been a bit more than 3 months since our last release (2023-11-10)
>>> [1] and there are currently 100+ new commits in main branch. Per our
>>> tradition of producing one release every 2-3 months, I think it's time
>>> to consider for next release now.
>>> 
>>> According to [2], the following release managers would be:
>>> - 1.37.0 Sergey Nuyanzin
>>> - 1.38.0 Julian Hyde
>>> 
>>> @Sergey, are you still available for being the release manager for 1.37.0?
>>> 
>>> Besides, we need more volunteers for the next releases (version >=
>>> 1.39.0), anyone who is interested in doing it can reply in this
>>> thread.
>>> 
>>> [1] https://calcite.apache.org/docs/history.html#v1-36-0
>>> [4] https://lists.apache.org/thread/tm3t42qvpq3db24xtd2g468ofv83l6hk
>>> 
>>> 
>>> --
>>> 
>>> Best,
>>> Benchao Li
>>> 
>> 
>> 
>> --
>> Best regards,
>> Sergey

Re: [DISCUSS] Towards Calcite 1.37.0

[Stamatis Zampetakis]

With so many commits it's definitely a good time to cut a new release.

I can be the RM for 1.39.0 or 1.40.0 depending on the timing.

Best,
Stamatis

On Wed, Feb 21, 2024 at 12:10 AM Sergey Nuyanzin  wrote:
>
> Thanks for starting the discussion
>
> > @Sergey, are you still available for being the release manager for 1.37.0?
>
> I think so, in theory I could start with some steps in one/two weeks if
> there is no objections
>
>
>
> On Mon, Feb 19, 2024 at 12:29 PM Benchao Li  wrote:
>
> > It's been a bit more than 3 months since our last release (2023-11-10)
> > [1] and there are currently 100+ new commits in main branch. Per our
> > tradition of producing one release every 2-3 months, I think it's time
> > to consider for next release now.
> >
> > According to [2], the following release managers would be:
> > - 1.37.0 Sergey Nuyanzin
> > - 1.38.0 Julian Hyde
> >
> > @Sergey, are you still available for being the release manager for 1.37.0?
> >
> > Besides, we need more volunteers for the next releases (version >=
> > 1.39.0), anyone who is interested in doing it can reply in this
> > thread.
> >
> > [1] https://calcite.apache.org/docs/history.html#v1-36-0
> > [4] https://lists.apache.org/thread/tm3t42qvpq3db24xtd2g468ofv83l6hk
> >
> >
> > --
> >
> > Best,
> > Benchao Li
> >
>
>
> --
> Best regards,
> Sergey

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

Thanks for starting the discussion

> @Sergey, are you still available for being the release manager for 1.37.0?

I think so, in theory I could start with some steps in one/two weeks if
there is no objections



On Mon, Feb 19, 2024 at 12:29 PM Benchao Li  wrote:

> It's been a bit more than 3 months since our last release (2023-11-10)
> [1] and there are currently 100+ new commits in main branch. Per our
> tradition of producing one release every 2-3 months, I think it's time
> to consider for next release now.
>
> According to [2], the following release managers would be:
> - 1.37.0 Sergey Nuyanzin
> - 1.38.0 Julian Hyde
>
> @Sergey, are you still available for being the release manager for 1.37.0?
>
> Besides, we need more volunteers for the next releases (version >=
> 1.39.0), anyone who is interested in doing it can reply in this
> thread.
>
> [1] https://calcite.apache.org/docs/history.html#v1-36-0
> [4] https://lists.apache.org/thread/tm3t42qvpq3db24xtd2g468ofv83l6hk
>
>
> --
>
> Best,
> Benchao Li
>


-- 
Best regards,
Sergey