Yeah, sorry, I don’t often use the GitHub ‘approve’ button. My verbal approvals 
are often conditional. The ‘approve’ button doesn’t allow nuance.

> On Sep 15, 2024, at 3:26 PM, Mihai Budiu <mbu...@gmail.com> wrote:
> 
> You have not listed CALCITE-4918, 
> https://issues.apache.org/jira/browse/CALCITE-4918 for which I have a PR, 
> which I think you have approved using comments 
> https://github.com/apache/calcite/pull/3947, but not using the official 
> "approve" button.
> 
> I was hoping other people would weigh on this design and implementation.
> 
> Mihai
> 
> ________________________________
> From: Julian Hyde <jh...@apache.org>
> Sent: Sunday, September 15, 2024 3:12 PM
> To: dev@calcite.apache.org <dev@calcite.apache.org>
> Subject: Re: [DISCUSS] Towards Calcite 1.38.0
> 
> I've logged https://issues.apache.org/jira/browse/CALCITE-6582 to
> track the release.
> 
> There are 26 open bugs [1] marked to fix for 1.38. I have organized
> them into 5 categories. Can people please review and merge those in
> category 1? To get a release vote next week, so let's get busy
> reviewing and merging bugs this week.
> 
> Category 1. The following have a PR available that seems close to
> ready. If these are good, let's get these merged!
> * CALCITE-6572 Add more tests for NULL arguments to TO_CHAR functions
> * CALCITE-6554 nested correlated sub-query in aggregation does not
> have inner correlation variable bound to inner projection
> * CALCITE-6550 Improve SQL function overloading
> * CALCITE-6343 AS alias operator strips MEASUREness from measures
> * CALCITE-6161 The equalsDeep of sqlCall should compare sqlOperator's sqlKind
> * CALCITE-6226 Wrong ISOWEEK and no ISOYEAR on BigQuery FORMAT_DATE
> * CALCITE-2067 RexLiteral cannot represent accurately floating point
> values, including NaN, Infinity
> * CALCITE-5156 Support implicit number type cast for IN Sub-query
> * CALCITE-6071 RexCall should carry source position information for
> runtime error reporting
> * CALCITE-6498 Elasticsearch multi-field mappings do not work
> * CALCITE-6522 MAP_KEYS and MAP_VALUES function should throw if a key
> value is null
> * CALCITE-6020 SqlToRelConverter should not replace windowed SUM with
> equivalent expression using SUM0
> * CALCITE-4512 GROUP BY expression with argument name same with SELECT
> field and alias causes validation error
> 
> Category 2. The following cases have a draft PR. Is it ready for 1.38?
> * CALCITE-6431 Implement the SINGLE_VALUE aggregation in
> HiveSqlDialect And SparkSQLDialect
> * CALCITE-6300 Function MAP_VALUES/MAP_KEYS gives exception when
> mapVauleType and mapKeyType not equals map Biggest mapKeytype or
> mapValueType
> 
> Category 3. Need to decide whether to accept or close:
> * CALCITE-6207 Improve connection resource in JDBCUtils
> * CALCITE-6411 Support Collect in ToLogicalConverter
> * CALCITE-6352 The map_contains_key function may return true when the
> key and mapkeytype types are different.
> 
> Category 4. The following seem to have no PR. Are there any worth
> holding the train for?
> * CALCITE-6277 About the processing of +infinity parameters and
> -infinity parameters in math function
> * CALCITE-6203 Avg operator test in SparkAdapterTest
> * CALCITE-6326 Add LOG10 and LN function (enabled in Mysql, Spark library)
> * CALCITE-6259 The implementation of the Log library operator does not
> match the actual dialect behavior.
> * CALCITE-5541 Upgrade JavaCC
> * CALCITE-6469 Join on condition generates wrong plan when the
> condition is IN sub-query
> * CALCITE-6463 alias generation issue about correlated subquery handling
> 
> Category 5. Are there any more cases with PR ready (i.e. potential category 
> 1)?
> 
> Julian
> 
> [1] 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20fixVersion%20%3D%201.38.0%20and%20resolution%20%3D%20Unresolved%20
> 
> On Fri, Sep 13, 2024 at 6:20 PM Xiong Duan <xi...@apache.org> wrote:
>> 
>> +1 We start voting in about ten days. We will merge the almost-ready PR.
>> 
>> Cancai Cai <caic68...@gmail.com> 于2024年9月14日周六 08:55写道:
>>> 
>>> +1,There are still many valuable PRs in Calcite. We can try to merge them 
>>> before 1.38.
>>> 
>>> [1] https://github.com/apache/calcite/pulls
>>> 
>>> Best wishes,
>>> Cancai Cai
>>> 
>>>> 2024年9月14日 04:04,Julian Hyde <jhyde.apa...@gmail.com> 写道:
>>>> 
>>>> +1 we’re ready for a release, and I’m happy to be RM.
>>>> 
>>>> I think we could have a first RC and vote in about ten days. What do 
>>>> others feel about timing?
>>>> 
>>>> Julian
>>>> 
>>>> 
>>>>> On Sep 13, 2024, at 4:58 AM, Benchao Li <libenc...@apache.org> wrote:
>>>>> 
>>>>> Last release date is 2024-05-06, sorry for the typo.
>>>>> 
>>>>> Benchao Li <libenc...@apache.org> 于2024年9月13日周五 19:52写道:
>>>>>> 
>>>>>> It's been a bit more than 4 months since our last release (2023-05-06)
>>>>>> [1] and there are currently almost 150 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.38.0 Julian Hyde
>>>>>> - 1.39.0 Stamatis Zampetakis (or maybe 1.40.0 depending on the timing)
>>>>>> - 1.40.0 Hongyu Guo
>>>>>> - 1.41.0 Jing Zhang (she said 1.39.0 in the ML, but according to the
>>>>>> order of the email, the next one should be 1.41.0)
>>>>>> 
>>>>>> [1] https://calcite.apache.org/news/2024/05/06/release-1.37.0/
>>>>>> [2] https://lists.apache.org/thread/kx56c4ow50g50hx2y8ybp631jmtnwnj6
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>> Best,
>>>>>> Benchao Li
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Best,
>>>>> Benchao Li
>>>> 
>>> 

Reply via email to