[
https://issues.apache.org/jira/browse/CALCITE-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722578#comment-16722578
]
Jacques Nadeau commented on CALCITE-2736:
-----------------------------------------
{quote}Regardless of which release it goes into, the change is producing
warnings relating to calls to deprecated APIs, so it shouldn't be in master. I
have put it onto a branch
[https://github.com/julianhyde/calcite/tree/2736-reduce-options] and
force-pushed to remove it from master. Let's merge it after the release, and
after the warnings are fixed.
{quote}
Can you share a link where this was decided (master should have no deprecation
warnings)? I'd like to review to better understand the thinking behind having
this rule but not enforcing in the build or pre-commit checks.
{quote}Policy is to release from master, not a spur. It produces a simple
change log, and holding back merges around release time is not too onerous for
a project of this velocity.
{quote}
I agree that a policy shouldn't be unilaterally dismissed without discussion.
That was definitely not my intent with this merge. The merge of Jesus's patch
without any discussion on the release thread was the second indicator that the
branch was open to me (beyond the lack of communication for some time on the
release thread). Per my comments above, there should be a clearer way to expose
this status. It would also preferably be time-bounded.
Side note: I disagree with your thoughts on the onerousness of this approach of
branch management. Two plus weeks of master lock is too long. I've hit this
several times in Calcite and I'd be surprised if I was alone. There is minimal
committer benefit of having a pure linear history for a few commit release spur
(even if you have to do a couple of cherry picks). I'll consider bringing this
up on the mailing list.
{quote}I don't want even minor changes to be added to this RC. Hive's regress
is in progress, and takes several days.
{quote}
It would have been nice to have clearer communication on the mailing list
around your goals with regards to the release and the timing. Until your post
today, your intentions, actions and timing weren't super clear.
> ReduceExpressionsRule never reduces dynamic expressions but this should be
> configurable
> ---------------------------------------------------------------------------------------
>
> Key: CALCITE-2736
> URL: https://issues.apache.org/jira/browse/CALCITE-2736
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Jacques Nadeau
> Assignee: Jacques Nadeau
> Priority: Major
> Fix For: 1.19.0
>
>
> There are situations where it is helpful to reduce dynamic SqlCalls. Right
> now, the ReduceExpressionsRule always avoids doing this. We should enhance
> the rule so this can be configurable depending on where in planning the rule
> is used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
