Merging the repositories is unnecessary, and a massive waste of time.
Any supposed “time savings” due to the the merged repositories will be eaten up
by dozens of small issues that will crop up long after the merge.
I was release manager for Calcite and Avatica this time around and it took me
about a week, because the process had changed since last time I was release
manager. And now we’re going to change the process again? Absolutely fucking
insane.
Also, we will lose the history of the Avatica source code. All of the commit
hashes for bugs fixed long ago will change.
At the time that we split the repositories, I was probably against the idea,
because it was work. Now that we’ve split, I am strongly against recombining
the repositories.
Honestly, people, we have better things to do.
Julian
> On Nov 9, 2021, at 1:03 PM, Stamatis Zampetakis <zabe...@gmail.com> wrote:
>
> The two projects have more or less the same release cadence, they're
> maintained by the same community, they're written in the same language, and
> they use the same build system.
>
> Although I understand the reasons the project was split in the first place,
> at the moment I tend to agree that having them in the same repo would be
> more practical.
>
> Truth is the merge may require quite a bit of work so we should take this
> into consideration.
>
> If people prefer keeping the projects as they are I am perfectly fine with
> that as well. I am leaving the decision to those who feel strongly about
> this change.
>
> Best,
> Stamatis
>
>
>
> On Tue, Nov 9, 2021, 7:46 PM Vladimir Ozerov <ppoze...@gmail.com> wrote:
>
>> +1 for a single repo.
>>
>> Вт, 9 нояб. 2021 г. в 19:22, Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com
>>> :
>>
>>> Michael> is not proposing to change the
>>> Michael>structure of modules within both projects, merely to have the
>> code
>>> for
>>> Michael>both in a single repository.
>>>
>>> I propose to integrate them into a single build, and keep the set of the
>>> published jars.
>>> However, the modules and dependency structure could be kept as is.
>>>
>>> We might want to rename folders like
>>> calcite-core
>>> calcite-linq4j
>>> ..
>>> avatica-core
>>> avatica-server
>>>
>>> However, I am not sure it is that important to discuss folder names now.
>>> The idea is that as you "open Calcite in IDE, you see both Avatica and
>>> Calcite modules"
>>>
>>> Michael>Is there any reason we couldn't have a separate release schedule
>> if
>>> Michael>both projects are in the same repository?
>>>
>>> A different schedule means Calcite must support at least two different
>>> Avatica versions.
>>> In other words, if we allow clients to update Avatica at their will, then
>>> we should allow them building Calcite with different Avatica versions,
>>> which implies Calcite test code should succeed for multiple different
>>> Avatica vesions.
>>>
>>> That makes it harder to write tests: we have to execute tests with two
>>> different Avatica releases (or even more than two).
>>>
>>> There are at least two sources for complexity:
>>>
>>> a) We have to write tests that tolerate multiple versions. For instance,
>>> "if (avatica.18+) {...}" and so on.
>>> That is not really trivial, especially taking into account some of the
>>> tests are created with non-yet-popular
>>> technologies like Quidem where you can't really google solutions. So the
>>> "trivial" task of "making a test to expect two possible outcomes"
>>> becomes less trivial as you try to pass the version from GitHub Action to
>>> Gradle to JUnit to Quidem to no-one-knows-which class.
>>> If we support one Avatica version only, that is not needed. We just patch
>>> the test in Avatica and Calcite and that is it.
>>> Single repo avoids "Gradle vs Quidem" dance.
>>>
>>> b) If we claim that we support 5 different Guava versions, 3 different
>> JDK
>>> versions, 2 different Avatica versions,
>>> then we have to execute 5*3*2 = 30 combinations of the tests.
>>> That is not really a full matrix, however, things get way easier if we
>>> support one Avatica version only.
>>> The amount of tests we need to do during a proper release is much less,
>> and
>>> it is easier to commit
>>> changes that touch Avatica and Calcite at the same time.
>>>
>>>
>>> Vladimir
>>>
>>
