I would think that the following are sufficient:
1. git ckeckout site
2. git rebase -i b8f4edfcf107aa99f9e8007b3f26f2b94ba7d341
3. pick the commits that should remain in the site normally just two:
d 2afea1fc9 Site: Elastic query example on _MAP
d 15a6d384f Site: Add Zoltan Haindrich as committer
Yes, I did it more complex than this just to sync exactly at the moment
after the release but if not necessary just rebase onto master.
Στις Τετ, 27 Μαρ 2019 στις 9:01 π.μ., ο/η Julian Hyde
έγραψε:
> I thought it would be straightforward.
>
> Checkout site, then rebase onto master. The site
I thought it would be straightforward.
Checkout site, then rebase onto master. The site branch should be a
subset of the commits on master branch, and those commits would turn
into no-ops.
On Wed, Mar 27, 2019 at 12:24 AM Stamatis Zampetakis wrote:
>
> I would think that the following are
Ruben Quesada Lopez created CALCITE-2959:
Summary: Support collation on struct fields
Key: CALCITE-2959
URL: https://issues.apache.org/jira/browse/CALCITE-2959
Project: Calcite
Issue
Firstly, thanks for managing the release 1.19.0, Kevin!
I don't know which way is better between "merge" and "rebase" when
unifying master and site, but it seems that we used a "rebase"[1] in
1.18.0 release.
And an interesting thing is, the GitHub's comparison page[2] shows some
I saw that Stamatis just did “git push origin a9687de81:site”. That’s somewhat
of an improvement, because it removes the merge commit, but it introduces a
problem: it includes “25ffeb4ac [CALCITE-2908] Implement SQL LAST_DAY
function”, and that commit updates the site with a function that will
I just forced pushed the current master a few minutes ago. From the
discussion this morning, I thought we concluded to this! Sorry if I
misunderstood.
Στις Τετ, 27 Μαρ 2019 στις 11:57 μ.μ., ο/η Haisheng Yuan <
h.y...@alibaba-inc.com> έγραψε:
> +1
>
>
>
>
>
> Thanks~
> Haisheng
>
+1 To Julian's amendment. Thanks for sorting this out, Julian + Stamatis.
The release process for Calcite is quite involved and can be somewhat
complex. I think we should consider adding explicit instructions to the
HOWTO document with the exact git commands need to even the site and
master
The site branch currently has a merge commit in it. But traditionally after a
release the site branch points to the same commit as the master branch.
So, any objections if I reset the site branch, as follows:
$ git checkout site
$ git reset —hard origin/branch-1.19
$ git push -f origin site
+1
Thanks~
Haisheng Yuan--
发件人：Francis Chuang
日 期：2019年03月28日 06:49:44
收件人：
主 题：Re: Site branch
+1 I think this should reduce the number of "commits ahead" in the site
branch compared to master to 0.
On 28/03/2019 9:46 am,
LGTM. Thanks for sorting this out!
--
Michael Mior
mm...@apache.org
Le mer. 27 mars 2019 à 19:12, Julian Hyde a écrit :
>
> I saw that Stamatis just did “git push origin a9687de81:site”. That’s
> somewhat of an improvement, because it removes the merge commit, but it
> introduces a problem: it
The Apache Jenkins build system has built Calcite-Master (build #1089)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1089/ to
view the results.
The Apache Jenkins build system has built Calcite-Master (build #1091)
Status: Failure
Check console output at https://builds.apache.org/job/Calcite-Master/1091/ to
view the results.
The Apache Jenkins build system has built Calcite-Master (build #1093)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1093/ to
view the results.
Lai Zhou created CALCITE-2960:
-
Summary: CalciteCatalogReader use a hard-coding config to get
functions
Key: CALCITE-2960
URL: https://issues.apache.org/jira/browse/CALCITE-2960
Project: Calcite
The Apache Jenkins build system has built Calcite-Master (build #1092)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1092/ to
view the results.
Thanks Hongze, that's good to know.
On Thu, Mar 28, 2019 at 8:43 AM Hongze Zhang wrote:
> > Besides, if I enable forceLaCheck, JavaCC suggests to use a lookahead of
> 3
> > or more. I guess we'd better get rid of these warnings if we want to
> stick
> > to lookahead(2).
>
> That makes sense.
> Besides, if I enable forceLaCheck, JavaCC suggests to use a lookahead of 3
> or more. I guess we'd better get rid of these warnings if we want to stick
> to lookahead(2).
That makes sense. Actually we had a discussion[1] on moving to "LOOKAHEAD=1",
and seems we are close to finish it. By doing
The Apache Jenkins build system has built Calcite-Master (build #1088)
Status: Failure
Check console output at https://builds.apache.org/job/Calcite-Master/1088/ to
view the results.
19 matches
Mail list logo
