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 > -- Best regards, Sergey
