Ok, I did not care when Avatica was split into its own repository, and I assumed Avatica team would maintain the code. That turned out to be not quite true, and it turns out there are non-trivial overheads coming from the split.
Of course, everybody can disagree, so if you disagree, you don't need to explain that. We just disagree and that is it. Now I do not care how Avatica would evolve further. It might be even good because Vladimir S won't bother Avatica with mails, PRs, and other random items. What I care much more about is that Calcite tests are broken, the CI reports failure for every commit, and that is really insane. Calcite CI must not fail on every build. I am going to delete/ignore the offending tests in Calcite in 24 hours, and I let the others deal with the case (fix tests, fix Quidem, merge Avatica, or whatever). I would no longer review calcite-avatica PRs. ---- Julian>I was release manager for Calcite and Avatica this time around and it took me about a week Julian, as the repositories are merged, there will be a **single** release process that releases both Calcite and Avatica in a single go. It would reduce the friction, and it would reduce cases where the release procedures and steps are "slightly different". It looks like you assume the release steps would never change, however, in practice, the drift of Java, Docker, OS, and so on versions would affect the release steps anyway. That is why having Avatica and Calcite in a single repository would simplify the release procedure. Julian> And now we’re going to change the process again? I propose to *drop* the release process for "calcite-avatica-java". The release of "calcite" would release both things (in a single calcite-x.y.z.tar.gz file), so the release steps for Calcite would be intact. Technically, that changes the process. In practice, I find that you overreact. The merge would make the release easier. On top of that, it was you who voted for splitting Calcite and Avatica, so it was your conscious decision to accept that "release management would get harder after the split" Julian>Any supposed “time savings” due to the merged repositories will be eaten up by dozens of small issues that will crop up long after the merge The words are not justified. There will always be some random small issues, even in the case we keep repositories separate. On the other hand, there are true issues when repositories are different: * We have two different release processes, so RM have to know the differences * we have slightly different dependency versions, so things like "bump junit" have to be duplicated * CI configuration is duplicated across the repositories, and it does have non-zero maintenance overhead * cross-repository refactorings are harder to do (like the fix for the exception message) Julian, I did put four issues that are real, and they induce noticeable maintenance churn. Java and JUnit will keep updating and you can't prevent that. Please highlight the problems exactly and please stop saying "time savings will be eaten by dozens". That is not a healthy discussion. >Also, we will lose the history of the Avatica source code. All of the commit hashes for bugs fixed long ago will change We can make calcite-avatica repository read-only, so all commits will be there. Vladimir
