Are you still advocating this change, Vladimir?
If this is something you want to continue discussing (I'm not sure if
your comment about "[I won't contribute to Avatica]" is saying that you
don't want to discuss this anymore), could we try to refocus this on
some specific technical problems that come up due to Avatica and Calcite
being separate repositories. If we identify these problems, we can think
through (from the beginning) if combining repositories is the only
solution or just one possible solution (and weigh the pros and cons for
each).
It seems like you also have some pain points with Calcite that you want
to improve, but these are separate from the discussion at hand. Let's
try to keep those out of a discussion about combining these two
repositories, please.
On 11/10/21 6:59 AM, Vladimir Sitnikov wrote:
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
