calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Fwd: [DISCUSS] fork Calcite and include the fork as a a submodule
Date Mon, 17 Apr 2017 17:36:05 GMT
Forwarding to dev@calcite (in bcc).

If anyone in Calcite wants to join the discussion, please reply to dev@kylin.

> Begin forwarded message:
> 
> From: hongbin ma <mahongbin@apache.org>
> Subject: [DISCUSS] fork Calcite and include the fork as a a submodule
> Date: April 16, 2017 at 7:39:12 AM PDT
> To: dev <dev@kylin.apache.org>, jhyde@apache.org
> 
> Recently I'm testing kylin connectivity with multiple BI tools like Tableau, Cognos,
etc. During the test I find it necessary to fix several Calcite issues, like CALCITE-1754.
I'm more than willing to contribute the fixes back to calcite, however there're still two
potential issues:
> 
> 1. Calcite has it's own release cycles, sometimes we cannot afford to wait for calcite's
next release
> 2. Some dirty hacks (yet still necessary) is not likely to be accepted by Calcite. Currently
there's a weird sub-project called "AtopCalcite" in Kylin to host all the dirty hacks. 
> 
> With the above two issues, I'm wondering what is the best way to interact with Calcite
releases. I'm suggesting that:
> 
> 1. We fork Apache Calcite and call it sth like calcite-for-kylin
> 2. Upon each calcite fix from our side, we double-commit to both Apache Calcite and calcite-for-kylin
> 3. For dirty hacks we only push code to calcite-for-kylin
> 4. calcite-for-kylin should be updated upon each Apache Calcite release
> 
> Any comment are welcomed!
> @Julian Looking forward to your comments as well
> 
> -- 
> Regards,
> 
> Bin Mahone | 马洪宾


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message