+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
