How fitting :)
It should be fairly simple -- let me put in a request to infra. Once we
have a repo, it should be self-service for us to move the stuff over there.
Julian Hyde wrote:
Thanks - I’ll rebase after the release.
I’m sitting in a cafe right now and there’s a guy right outside the window
re-potting the plant pots: pull up each plant individually, pull its roots
apart from other plants, and put into a new pot with more room around it to
grow.
We should definitely do that with Calcite/Avatica. If someone has the time and
energy to move Avatica into a separate repo I will support that.
Julian
On Mar 20, 2017, at 9:34 AM, Josh Elser<[email protected]> wrote:
Oops, sorry for causing some pain, Julian. I'm ok with a rebase/force-push. It
completely slipped my mind that I should have held off on those commits :)
I still think separating out Avatica from the Calcite repo would be better long
term (Shi had gotten confused over this, recently), but, like you said, it's a
pretty minor thing.
Julian Hyde wrote:
Josh,
I see you made 3 commits to Calcite’s master branch yesterday to fix Avatica
issues. There is a release vote for Calcite underway, and the last few changes
for that are in branch-1.12 but not in master. Up to this point we have been
able to keep the commit tree linear (i.e. there are no merge commits with two
parents), and I would like to retain that.
To keep the tree linear, I will need to rebase master onto branch-1.12 after
the release, then do a force push to master. Is that OK with you?
Devs,
Going forward, there are several solutions (lock the repository during release
votes, force push to master after a a release, and allow the repository to have
merge commits). And splitting the Calcite and Avatica repositories would at
least allow Avatica development to continue during Calcite release votes. We
should discuss the various options. But in my opinion, we are still small
enough that the current policy (pausing commits during release votes, to keep a
linear release history) is working fine.
Julian
