I know the below is too wordy, however, English is not my native language, so I tend to overexplain and duplicate thoughts.
Julian>To allow separate communities This is something I do not understand. Let me be explicit: I am OK to maintain bits of avatica code when Calcite fixes overlap with Avatica for some reason (e.g. throwing exceptions). I am not OK with duplicating the same work just because someone else wants to have a separate repository. I was maintaining and releasing multiple (four!) repositories for pgjdbc when it was using Maven (Maven was not able to release jre6, jre7, and jre8 artifacts from within a single repository), and it was a big relief when the code was recollected into a single repository again. That is why I am advocating for merging avatica code back. Julian>Splitting code into modules makes it easier to continue to splitting I agree it is worth having calcite-core and avatica as separate jar artifacts. It is even worth splitting "enumerable" out of calcite-core into its own module. However, I do not see how splitting the repositories helps. I do not expect somebody to use calcite-avatica as a git submodule or something like that. Julian>to allow separate release schedules Here are the recent releases. There's often a pattern that "Calcite release follows Avatica release". It is even mentioned in the mails where someone suggests releasing Avatica, then releasing Calcite". A notable exception was rel/avatica-1.16.0 which was not connected to the release of Calcite. The rest Avatica releases seem to be quite close to Calcite releases, so I do not see what do we gain from "separate release schedules". It looks like co-locating the release would be easier for both maintenance overheads, testing, and consumption. 2016-03-16 rel/calcite-avatica-1.7.0 2016-03-17 calcite-1.7.0 2016-03-15 rel/calcite-avatica-1.7.1 2016-06-01 rel/calcite-avatica-1.8.0 2016-06-08 calcite-1.8.0 2016-09-17 calcite-1.9.0 2016-10-07 calcite-1.10.0 2016-10-27 rel/calcite-avatica-1.9.0 2017-01-03 calcite-1.11.0 2017-03-20 calcite-1.12.0 2017-05-23 rel/avatica-1.10.0 2017-06-22 calcite-1.13.0 2017-09-27 calcite-1.14.0 2017-12-05 calcite-1.15.0 2018-03-06 rel/avatica-1.11.0 2018-03-14 calcite-1.16.0 2018-06-21 rel/avatica-1.12.0 2018-07-16 calcite-1.17.0 2018-11-29 rel/avatica-1.13.0 2018-12-18 calcite-1.18.0 2019-03-20 calcite-1.19.0 2019-04-25 rel/avatica-1.14.0 2019-05-09 rel/avatica-1.15.0 2019-06-19 calcite-1.20.0 2019-09-06 calcite-1.21.0 2019-12-19 rel/avatica-1.16.0 2020-05-23 calcite-1.23.0 2020-06-22 rel/avatica-1.17.0 2020-07-23 calcite-1.24.0 2020-08-22 calcite-1.25.0 2020-10-06 calcite-1.26.0 2021-05-18 rel/avatica-1.18.0 2021-06-03 calcite-1.27.0 2021-10-04 rel/avatica-1.19.0 2021-10-19 calcite-1.28.0 Julian>The last of these was particularly on my mind when we split Avatica from Calcite. Julian>I was pleased to see, for example, Apache Phoenix using Avatica successfully (including building an ODBC driver) Does it really help Phonenix that we split repositories? I am sure they should not really depend on the repositories. How would their life be harder if we release the same set of artifacts and jars from a single source tree? Julian>If Avatica had remained part of Calcite, both written in Java and using the same build system and release process, Julian>it’s less likely that Avatica-go would have happened Does Avatica-go use calcite-avatica repository? So far it looks like Avatica-go uses https://github.com/apache/calcite-avatica-go, and I do not suggest merging it into calcite repository yet. I do not see how merging calcite-avatica and calcite repositories would block the evolution or emergence of avatica-go, avatica-rust, etc. Julian>release process I identified https://issues.apache.org/jira/browse/CALCITE-4881 "Calcite release tags should have rel/... prefix as per the ASF requirements" It looks like an unintentional breakage in https://github.com/apache/calcite/commit/2e30293af7373b6c5fbcc5fa6505b49df2fba000 caused by the split. Vladimir
