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
