Please work with the calcite project rather than forking. They are good guys and should be able to help. In terms of the hacks, can you figure out hooks in calcite that would let you accomplish there same goal?
.. Owen > On Apr 17, 2017, at 06:50, Li Yang <[email protected]> wrote: > > We should contribute all back to calcite except for those dirty hacks. The > question remains is how to sync the release cycles between kylin and > calcite. How to handle those patches that are important to kylin but not so > urgent to calcite. Having a fork of calcite obviously is a solution. But I > too don't know whether it is common and appropriate in the open source > world. > > Yang > >> On Sun, Apr 16, 2017 at 10:39 PM, hongbin ma <[email protected]> wrote: >> >> 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 | 马洪宾* >>
