Hi Owen First of all, even if with the fork, we're still "working with calcite" by constantly syncing new calcite codes(upon each calcite release) and contributing back to calcite (PR from our fork to calcite). *We're not saying goodbye to calcite.*
Let's forget about the dirty hacks. The key issue here should be un-synced release cycles between kylin and calcite. Very often we're blocked at some minor calcite issues, and we can fix them by small patches of calcite. However the fact that we have to wait for months for a new calcite release may trouble kylin users. On Mon, Apr 17, 2017 at 3:05 PM, Owen O'Malley <[email protected]> wrote: > 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 | 马洪宾* > >> > -- Regards, *Bin Mahone | 马洪宾*
