I’d be OK with that. I think we should firm up a plan at https://issues.apache.org/jira/browse/CALCITE-1717 <https://issues.apache.org/jira/browse/CALCITE-1717> before we act. Let’s continue discussion there.
Do you think we need a formal vote for this change? Repositories are pretty fundamental to the integrity of the project, so I’m inclined to think we do. Julian > On Mar 21, 2017, at 11:37 AM, Josh Elser <[email protected]> wrote: > > Michael's latter suggestion is what I was thinking about :) > > I've gone ahead and put in the request for an Avatica repo. We can do > whatever we want with it then. > > On Mon, Mar 20, 2017 at 6:11 PM, <[email protected]> wrote: >> You can use git subtree split to extract the Avatica commits into a new >> repository. This would maintain the history but would generate new commit >> IDs. Alternatively the history could start with the entire Calcite history >> with the first commit being one which deletes all non-Avatica files. >> >> -- >> Michael Mior >> [email protected] >> >> From: Julian Hyde >> Sent: Monday, March 20, 2017 18:09 >> To: [email protected] >> Subject: Re: Commits during release vote >> >> 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 >>>>>> >>>> >> >>
