Thanks for driving this release, sergey! -- Best regards, Hongyu
On Tue, May 7, 2024 at 3:42 PM Sergey Nuyanzin <snuyan...@gmail.com> wrote: > Thanks a lot Francis! > > I was able to finish it, > now the main code freeze is over and commits can be resumed. Thank you all > who was involved in the release of 1.37.0. > > On Tue, May 7, 2024 at 1:40 AM Francis Chuang <francischu...@apache.org> > wrote: > > > 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 > > >> > > > > > > > > > > > -- > Best regards, > Sergey >
