Re: [VOTE] Move to GitHub PR-centric development workflow, phase out JIRA

It's just my preference. I do not think current workflow is so painful that we have to replace it. Would the GitHub workflow boost our review? I doubt it somehow. Actually, I like the current workflow. Not only because I am used to it, but also it is easier to review all the discussions. Best,

Re: calcite-core 1.28.0 now depends on kotlin-stdlib?

Suppose that the dependencies were uploaded to the RC site, such as https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.23.0-rc0/ . Then people voting on the RC could compare those dependencies with the

Re: Snowflake VARIANT support

One other thought. Snowflake used the new ‘:’ operator to obtain fields of variants. Drill uses the existing ‘.’ operator. It’s possible that the ‘.’ operator will work just fine. In which case I would propose to implement ‘.’. Then we don’t need to change the parser. (Though there would be

Re: [DISCUSS] Calcite 1.29.0 release

https://calcite.apache.org/docs/howto.html#making-a-release-candidate > On Dec 6, 2021, at 1:36 PM, Rui Wang wrote: > > I am planning to spend some time this week to learn about the Calcite > release process, check

Re: [DISCUSS] Calcite 1.29.0 release

I am planning to spend some time this week to learn about the Calcite release process, check preparation works and plan for a timeline. IIRC I saw a documentation somewhere about the release process. if it is true can someone point me to the right page? -Rui On Tue, Nov 23, 2021 at 3:45 PM

Re: Enable "squash and merge" button in GitHub UI

I wonder if we can add GitHub action that would react to committers comment /squash by squashing the commits and pushing --force-with-lease to the fork branch. If pushing to the fork is not possible in GHA, then something like /merge that squashes, rebases and pushes to apache/calcite would be

Re: Feedback on a generic return type version of RelShuttle?

> On Dec 4, 2021, at 9:41 PM, Jacques Nadeau wrote: > > A few thoughts: > > Algebra approach. > > > If I understand the model correctly, I actually implemented this in a > different project last year (not knowing it was now a design pattern). My > main finding was that while it had certain

Re: [DISCUSS] JIRA vs GitHub Issues

Thanks for moving the discussion here, Vladimir. First of all, I honestly appreciate the fact that you launched this discussion, I think you raised some valid points; what you propose sounds reasonable, and it seems a valid approach too. My main argument is that I have no big issues with the

Re: Snowflake VARIANT support

Hello, Just to be clear, I do think supporting VARIANT in Calcite will be great and all the notes made by Julian under the JIRA make perfect sense. Below, there is another viewpoint for those people who don't need the full capabilities of a VARIANT type. In some cases, the data stored in a

Re: [DISCUSS] JIRA vs GitHub Issues

Moving the reply to DISCUSS thread. Ruben>My vote might be biased because I have used Jira for many years (and I have Ruben>never used Github for issue tracking). It is really sad to hear. You authored 87 PRs for Calcite! You did use GitHub for tracking already.

Re: [VOTE] Move to GitHub PR-centric development workflow, phase out JIRA

-1 I am satisfied with the current situation. My vote might be biased because I have used Jira for many years (and I have never used Github for issue tracking). I have the impression that some of the problems described discussion are not per se Jira-related, but they appear because we misuse the

Re: [VOTE] Move to GitHub PR-centric development workflow, phase out JIRA

>I think JIRA works well. I would appreciate it if you could clarify. What I suggest would work better than JIRA in virtually all the cases. So why stick with JIRA? Vladimir