I’m not sure what are the options for splitting a git repo. Do you think that the avatica repo will retain the commit ids of the current repo? (Presumably to do that we need to keep all of the calcite commits, then delete the calcite files.) Or do you think the new repo should start from an empty history and contain only avatica commits?
I’ve logged https://issues.apache.org/jira/browse/CALCITE-1717 <https://issues.apache.org/jira/browse/CALCITE-1717> to track. We could also consider, at some point, asking for an AVATICA prefix for JIRA cases. Julian > On Mar 20, 2017, at 2:12 PM, Josh Elser <[email protected]> wrote: > > 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 >>>> >>
