On 11/10/21 3:48 PM, Vladimir Sitnikov wrote:
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.
These are not things that are broken. CI configuration, JUnit versions,
and build configuration are already defined for each project. If you
want to change them, you can submit a change and test them. It sounds
like you want to be able to change them in exactly one place which (I am
to assume) is a personal motivation for yourself.
Cross-repository PRs, I've already addressed that this is a solved
problem. Please illustrate an example how this creates more code that
you have to write, because I genuinely do not see how this approach
creates more code that needs to be written than if the projects were in
the same repository.
1. Update avatica
2. Release avatica
3. Upgrade avatica dependency in calcite with corresponding changes due
to avatica upgrade.
In your example where avatica is in the code base, it discourages API
semantics to *not* be compatible by allowing you to quickly change the
Avatica API and immediately reflect those changes in Calcite. If folks
start doing this, then you disrupt the entire Calcite developer base who
has to realize that the API they wanted to use is no longer the correct API.
> If you have suggestions on how to bump JUnit and CI configuration in
both repositories at once
You are correct in that I do not believe this to be a "problem".
> It is clear that having the repositories separate has no real benefits.
This is not a fact, but this is your opinion.
> committers are the same
The PMC is the same and those authorized to make commits to each are the
same group, but the individuals are *not*. For example, I know damn well
that I should not go merging changes that I make into Calcite because I
do not regularly do this. In the same way, I'd expect 90%+ of the
Calcite committers have never contributed to Avatica.
If your opinion is some philosophical issue with the PMC governance
being shared between Avatica and Calcite, we can have that discussion
instead.
> I am sure those "reasons" have no weight
Again, this is your opinion. The fact is that I have made Avatica
releases without the burden of making a Calcite release, and I know that
multiple Calcite releases have been made without the burden of making a
new Avatica release. This is not "theoretical".
Avatica 1.17.0 was released Jun 2020, 1.18.0 in May 2021. Calcite had 3
releases of its own between these.
> If so, I just let them do the maintenance.
That is what I would prefer you to do.
> Avatica is stuck with Gradle 6.8.1
I can still build Avatica with Gradle 6.8.1.
Let me be clear to remove all doubt at this point in time: I am -1 on
combining these repositories based on the current discussion.
