I added you as an Administrator in Jira, you should be able to do it now.
Francis
On 7/05/2024 8:38 am, Sergey Nuyanzin wrote:
Hi everyone
I'm in process of publishing Calcite release and I need PMC help for jira
It looks like I don't have enough grants to mark release released (I don't
have these buttons on that tab)
Could someone from PMC please help me with this?
On Mon, Apr 29, 2024 at 8:57 AM Sergey Nuyanzin <snuyan...@gmail.com> wrote:
Hi everyone,
I created RC 3
however as I mentioned in the RC3 thread there is an issue with Arrow
adapter
that it is not supported on Windows, as a result it is not able to pass
tests on Windows.
I noticed that there are some links to Arrow docs telling that there is no
official support for Windows [1],
at least it is stated that it is regularly tested on Linux and Mac.
From Calcite's point of view it means that building and testing from
sources like `./gradlew clean build`
will not work anymore on Windows. Now on Windows we should have something
like `./gradlew clean build --exclude-task :arrow:build`
I'm not sure we can do much about it, I created a jira issue and placed
some observations there [2].
However it looks like the only thing we can do about it is mentioning this
in breaking changes and howtos for instance hot to build from sources.
Please correct me if I'm wrong
[1] https://arrow.apache.org/docs/java/install.html#system-compatibility
[2] https://issues.apache.org/jira/browse/CALCITE-6390
On Mon, Apr 22, 2024 at 9:20 PM Sergey Nuyanzin <snuyan...@gmail.com>
wrote:
Hi devs,
As it was mentioned earlier in order to an RC I'll start the
release process now. Therefore main branch is in code freeze until
further notice.
On Sun, Apr 21, 2024 at 2:22 AM Benchao Li <libenc...@apache.org> wrote:
+1 to produce one RC on the next Monday!
Stamatis Zampetakis <zabe...@gmail.com> 于2024年4月19日周五 21:55写道：
I agree with others that we shouldn't wait too long for cutting a
release. I am pretty sure there are many good PRs that can be merged
but nobody prevents us from making another release once this is done.
Having an RC on Monday would be great.
For people who may be completely familiar with all our
processes/tools, I outline below two points that are somewhat relevant
to the discussion so far.
In general we don't have a strict review-then-commit (RTC) policy for
merging changes in Calcite. In various cases committers of the project
can merge changes without getting an explicit approval. This shouldn't
happen for risky or debatable patches but it is fine to do that for
addressing small bugs, minor improvements, etc. It's up to the
discretion of the committer to decide when to merge a change.
All JIRA activities (conversations, updates, etc.) can be tracked by
subscribing to the issues@calcite list. People who are subscribed to
issues@ receive notifications for every JIRA ticket even if they are
not following a particular ticket.
Best,
Stamatis
On Thu, Apr 18, 2024 at 9:29 PM Sergey Nuyanzin <snuyan...@gmail.com>
wrote:
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 <mbu...@gmail.com>
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 <francischu...@apache.org>
Sent: Wednesday, April 17, 2024 9:05 PM
To: dev@calcite.apache.org <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 <francischu...@apache.org> 于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 <mbu...@gmail.com>
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 <snuyan...@gmail.com>
Sent: Monday, April 8, 2024 2:32 PM
To: dev@calcite.apache.org <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 <mbu...@gmail.com>
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 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 <francischu...@apache.org>
*Sent:* Sunday, March 17, 2024 2:44 PM
*To:* dev@calcite.apache.org <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 <guohongyu...@gmail.com> 于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 <
snuyan...@gmail.com>
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 <
jhyde.apa...@gmail.com
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 <
zabe...@gmail.com
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 <
libenc...@apache.org>
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
--
Best regards,
Sergey
--
Best regards,
Sergey
--
Best,
Benchao Li
--
Best regards,
Sergey
--
Best regards,
Sergey
