Agreed on all points. Let me put some thought into it and get a plan on
1717 tonight.
Julian Hyde wrote:
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
