Thanks for chiming in, Jacques. I was going to mention Drill as an example that the Kylin community could learn from.
Also, thanks for starting this discussion, Hongbin Ma. Although “fork” is a scary word, it’s good to talk about development process so that we can find a process that works for everyone. I strongly recommend that you stay on (or very near) Calcite master. As Jacques says, when you get too far off master it’s really difficult to catch up[1]. (“Very near” might mean that you make a release with one or two extra patches that you believe will land in Calcite master very shortly. It’s up to you to be disciplined and make sure that happens.) At Calcite we are committed to providing releases in a timely fashion. We *need* to do this because, as a framework, some of our major clients are Apache projects (Drill and Hive initially, but now including Kylin, Flink, Apex, Storm and several others). We *can* do this because we keep master branch stable. At a pinch, we could probably do a release from a standing start in a week (including a 3 day vote). But if you know you need a release by a particular date, we can accommodate that. Typically there is a discussion about timing a few weeks before a release, e.g. [2], and if you chime in, your voice will be heard. Remember that Calcite’s and Kylin’s interests are aligned. We want to have good support for Tableau just as much as you do. If you contribute a fix for Tableau, we are strongly motivated to accept it. That said, it does not benefit our community if we accept incomplete contributions (say, those without adequate test cases or documentation). We know from experience that once we accept crappy code, we own it. So, if you want to get a contribution accepted, make sure that it is complete and high quality, and be prepared to work with us to address our concerns. Then we will commit to keeping that feature (and in particular your tests) working in future releases. Lastly, JIRA cases and test cases are very welcome even without a fix. If you contribute a good test case, maybe someone else from the Calcite community will fix it. If you contribute a good suite of tests to Calcite’s suite for features that Kylin depends on, upgrading Kylin to a new release of Calcite will become easier. Julian [1] https://issues.apache.org/jira/browse/DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993> [2] https://mail-archives.apache.org/mod_mbox/calcite-dev/201612.mbox/%3C21C662E4-3C33-4633-AF34-728F6D84BA61%40apache.org%3E <https://mail-archives.apache.org/mod_mbox/calcite-dev/201612.mbox/%[email protected]%3E> > On Apr 17, 2017, at 10:52 AM, Jacques Nadeau <[email protected]> wrote: > > I was probably the key person behind forking Calcite for Drill's purpose > (3+ years ago). It was mostly driven by being unable to get key patches > into Calcite. It has become a mistake. I suggest you avoid making the same > one. Calcite is moving too quickly and you'll fall behind and be stuck in > fork-land. > > - If you can't get something merged and that is your impetus, please > elevate that discussion. > - If you need more frequent releases, you need to ask for them. > > For the second item, if you or someone else on Kylin becomes PMC/committer, > you can also get to the point where you are someone who can drive these > point releases. Looking at history, no one in the Calcite community has > ever said "no, we can't do another release". Someone says "let's do a > release" and then we do one. > > > >>> From: hongbin ma <[email protected]> >>> Subject: [DISCUSS] fork Calcite and include the fork as a a submodule >>> Date: April 16, 2017 at 7:39:12 AM PDT >>> To: dev <[email protected]>, [email protected] >>> >>> 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 | 马洪宾 >> >>
