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 <[email protected]> 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 <[email protected]> > Sent: Wednesday, April 17, 2024 9:05 PM > To: [email protected] <[email protected]> > 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 <[email protected]> 于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 <[email protected]> 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 <[email protected]> > >>>> Sent: Monday, April 8, 2024 2:32 PM > >>>> To: [email protected] <[email protected]> > >>>> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > >>>>>> *Sent:* Sunday, March 17, 2024 2:44 PM > >>>>>> *To:* [email protected] <[email protected]> > >>>>>> *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 <[email protected]> 于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 < > >>>>>>>> [email protected]> 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 < > [email protected]> > >>>>>> 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 < > >>>> [email protected] > >>>>>> > >>>>>>>>>> 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 < > >>>>> [email protected] > >>>>>>> > >>>>>>>>>>> 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 < > >>>>>>>>> [email protected]> > >>>>>>>>>>> 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 < > >>>>> [email protected]> > >>>>>>>>>>> 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
