I agree with Vladimir. Although i am very new here but in my mind having one repository will reduce lot of efforts while not necessarily it will reduce flexibility and modularity of the the project.
My initial impression is that we can achieve the same modularity constraints even after merging the code into one repo. Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Vladimir Sitnikov <[email protected]> Sent: Tuesday, November 9, 2021, 12:38 To: Apache Calcite dev list Subject: Re: DISCUSS: merge calcite-avatica and calcite repositories 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
