Josh>I have no objections to combining these two repositories together. Why don't we just merge the repositories and move on then?
Josh>If we identify these problems, we can think Josh>through (from the beginning) if combining repositories is the only Josh>solution or just one possible solution (and weigh the pros and cons for Josh>each). I am sure I did explain the pain points. See points 1..5 (the very beginning of the mail) in the very first message in this thread. If that is not enough, I can't really explain better. CI configuration is duplicated across repositories. JUnit versions maintenance overheads are duplicated. Build configuration is duplicated (e.g. code style rules, boilerplate build scripts, etc) Cross-repository PRs are non-trivial. And so on. If you have suggestions on how to bump JUnit and CI configuration in both repositories at once, you are welcome, however, the only alternative "solution" I expect is to ignore the problem and treat it as "not a problem". I acknowledge merging repositories will make some use cases harder. However, I am sure points 1..5 (see the very first mail) have no solution besides repository merge. It is clear that having the repositories separate has no real benefits. Community is the same, committers are the same, language is the same, releases are co-located. There are theoretical reasons like "different repositories allow different committers in theory" or "different repositories allow different release schedules" or "because people perceive that they can use component A without using component B" However, I am sure those "reasons" have no weight. They are theoretical, and some of them turned out to be false. For instance, the release schedule is co-located across several years. Even at the time of the Avatica split, somebody said that Solr community did **merge** repositories after a while exactly because the committers were effectively the same. Of course, somebody might **believe** that "because people perceive that they can use component A without using component B" is way more important than a non-important duplication of maintenance of CI, dependencies, build scripts across both repositories. You know what? I am fine to accept people might have those beliefs. If so, I just let them do the maintenance. Of course, you might claim that your ability to watch "avatica PRs only" is far more important. Is that really the key point of having separate repositories? Really? GitHub has "code owners" and "labeling" features, so you can watch the relevant parts of the repository. Josh>These repositories are separate because they have separate release Josh>schedules The release dates for Calcite and Avatica are co-located (see my mail above). The feature of "separate release schedules" is not really used in practice. Having the same version number for Calcite and Avatica would event make it easier for clients to pick the compatible versions. Josh> The net amount of code you have to write doesn't Josh> change with how it works now compared to how you are suggesting it Josh> should work. This is false. For instance, "CI configuration, JUnit versions, build scripts" are **duplicated** across repositories, so if the repositories are different, then the amount of work is increased. Here's one more data point: Calcite is built with Gradle 7.3, and Avatica is stuck with Gradle 6.8.1 Of course, the duplication of work does not exist. You say "the net amount of code I have to write doesn't change". You are right. I won't contribute to calcite-avatica repository anymore, so there's no duplication of work for me. Josh>If there are breaking changes in Avatica, they would need to be Josh>accounted for when Calcite is bumped to the next version of Avatica. calcite-avatica/pull/161 would be way easier if both avatica and calcite were in a single repository. There would be no need to think of version compatibility, etc. Josh> Having a separate repository makes it Josh>extremely easy for me to watch Avatica commits/pull-requests which I am Josh>capable of reviewing vs. Calcite pull-requests which I am not Josh>comfortable reviewing. Have you considered mail filters and/or code owners https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners ? There's an option to automatically label PRs according to the modified files via GitHub Action. Josh>rather than starting from the root problem "How can we Josh>make co-dependent changes easier?" "co-dependent" changes are not the only problem. It was just a trigger. Vladimir
