You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Ruben Q L <ru...@gmail.com> on 2020/09/23 18:36:37 UTC

[DISCUSS] Towards Calcite 1.26.0

Hi all,

It has been around one and a half months since our last release (1.25.0),
and it seems a good moment to start discussing our next one 1.26.0.

As we can see in our Jira dashboard [1] there are a few unresolved issues
for 1.26.
However, we have 180+ open pull requests [2], some of them seem in good
shape, even though their corresponding Jira tickets do not specify 1.26 as
"fix version", so they do not appear in the Jira dashboard. I encourage
contributors to take a look at these open issues, in order to confirm what
can / should be included in the next release.

Ideally, I would like to generate a RC by the end of next week.

Do not hesitate to reply to this thread if the plan above is not
convenient for you.

Best regards,
Ruben

[1]
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
[2] https://github.com/apache/calcite/pulls

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Thanks for the answer Danny.
If I am not mistaken, CALCITE-2569 and CALCITE-3923 were released with
1.25.0 (not 1.26.0), and were correctly flagged as breaking changes in the
previous release's breaking changes section.

Best,
Ruben


On Sun, Oct 4, 2020 at 3:16 AM Danny Chan <yu...@gmail.com> wrote:

> AFAIK,
>
> • CALCITE-4279: the SEARCH operator is a new one and causes the RexNode
> tree change which is breaking because downstream projects need to adapter
> for it
> • CALCITE-2569: the UDF needs to implement a new interface SqlTableFunction
> • CALCITE-3923: many singletons are removed and breaking
>
>
> Best,
> Danny Chan
> 在 2020年10月3日 +0800 AM1:12,Ruben Q L <ru...@gmail.com>,写道:
> > I'm working on the release notes, any breaking change worth mentioning
> > apart from https://issues.apache.org/jira/browse/CALCITE-2082 ?
> >
> >
> > On Fri, Oct 2, 2020 at 11:59 AM Ruben Q L <ru...@gmail.com> wrote:
> >
> > > Thanks for the answer Vladimir.
> > > ----
> > >
> > > I have a tight schedule today. I hope to generate a RC0 today or worst
> > > case scenario tomorrow.
> > >
> > > Best,
> > > Ruben
> > >
> > >
> > > On Fri, Oct 2, 2020 at 11:47 AM Vladimir Sitnikov <
> > > sitnikov.vladimir@gmail.com> wrote:
> > >
> > > > Ruben>Could someone that has recently built a release using the new
> > > > gradle-based
> > > > Ruben>process confirm this point?
> > > >
> > > > oh, that was a question by Ruben, and I copy-pasted the wrong name :)
> > > >
> > > > Vladimir
> > > >
> > >
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Danny Chan <yu...@gmail.com>.
AFAIK,

• CALCITE-4279: the SEARCH operator is a new one and causes the RexNode tree change which is breaking because downstream projects need to adapter for it
• CALCITE-2569: the UDF needs to implement a new interface SqlTableFunction
• CALCITE-3923: many singletons are removed and breaking


Best,
Danny Chan
在 2020年10月3日 +0800 AM1:12,Ruben Q L <ru...@gmail.com>,写道:
> I'm working on the release notes, any breaking change worth mentioning
> apart from https://issues.apache.org/jira/browse/CALCITE-2082 ?
>
>
> On Fri, Oct 2, 2020 at 11:59 AM Ruben Q L <ru...@gmail.com> wrote:
>
> > Thanks for the answer Vladimir.
> > ----
> >
> > I have a tight schedule today. I hope to generate a RC0 today or worst
> > case scenario tomorrow.
> >
> > Best,
> > Ruben
> >
> >
> > On Fri, Oct 2, 2020 at 11:47 AM Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com> wrote:
> >
> > > Ruben>Could someone that has recently built a release using the new
> > > gradle-based
> > > Ruben>process confirm this point?
> > >
> > > oh, that was a question by Ruben, and I copy-pasted the wrong name :)
> > >
> > > Vladimir
> > >
> >

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
I'm working on the release notes, any breaking change worth mentioning
apart from https://issues.apache.org/jira/browse/CALCITE-2082 ?


On Fri, Oct 2, 2020 at 11:59 AM Ruben Q L <ru...@gmail.com> wrote:

> Thanks for the answer Vladimir.
> ----
>
> I have a tight schedule today. I hope to generate a RC0 today or worst
> case scenario tomorrow.
>
> Best,
> Ruben
>
>
> On Fri, Oct 2, 2020 at 11:47 AM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
>> Ruben>Could someone that has recently built a release using the new
>> gradle-based
>> Ruben>process confirm this point?
>>
>> oh, that was a question by Ruben, and I copy-pasted the wrong name :)
>>
>> Vladimir
>>
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Thanks for the answer Vladimir.
----

I have a tight schedule today. I hope to generate a RC0 today or worst case
scenario tomorrow.

Best,
Ruben


On Fri, Oct 2, 2020 at 11:47 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> Ruben>Could someone that has recently built a release using the new
> gradle-based
> Ruben>process confirm this point?
>
> oh, that was a question by Ruben, and I copy-pasted the wrong name :)
>
> Vladimir
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Vladimir Sitnikov <si...@gmail.com>.
Ruben>Could someone that has recently built a release using the new
gradle-based
Ruben>process confirm this point?

oh, that was a question by Ruben, and I copy-pasted the wrong name :)

Vladimir

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Vladimir Sitnikov <si...@gmail.com>.
Vladimir>Could someone that has recently built a release using the new
gradle-based
Vladimir>process confirm this point?

I developed Gradle-based scripts, and one of the intentions was that no
commits should be made during the release.
No commits required to switch "release-snapshot" versions as well.

In other words, you get Git tree to the way you like it (e.g. update
release notes, fix tests, etc), then you prepare RC and Release
artifacts from exactly the same Git sha.

Vladimir

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Thanks for the answer Stamatis.
Could someone that has recently built a release using the new gradle-based
process confirm this point?

Thanks
Ruben


On Fri, Oct 2, 2020 at 10:42 AM Stamatis Zampetakis <za...@gmail.com>
wrote:

> Hi Ruben,
>
> If I remember well, you should commit them under CALCITE-4291 and then
> proceed with the release.
>
> Best,
> Stamatis
>
> On Fri, Oct 2, 2020 at 11:06 AM Ruben Q L <ru...@gmail.com> wrote:
>
> > Hello,
> >
> > thanks everyone for your effort pushing the remaining issues forward.
> > We enter a code freeze in order to generate a RC0 for 1.26.0, so please
> DO
> > NOT commit into master until further notice.
> >
> > To our expert release managers, I have a stupid question about "how-to
> > making a release candidate" instructions [1]:
> > The changes that I need to "check" and "add" (README,
> >  site/_docs/history.md, site/_docs/howto.md), do I need to commit those
> > changes myself before starting the RC0 generation process; or I just need
> > to make those changes locally, leave them uncommitted, because they will
> > get automatically committed during the RC generation (or publication)
> > process?
> >
> > Best regards,
> > Ruben
> >
> > [1]
> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> >
> >
> > On Thu, Oct 1, 2020 at 8:04 AM Ruben Q L <ru...@gmail.com> wrote:
> >
> > > FYI, AppVeyor issue has been resolved.
> > > Thanks Julian and Vladimir for your help!
> > >
> > > On Wed, Sep 30, 2020 at 7:32 PM Julian Hyde <jh...@gmail.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> > PS. I wonder what everybody think of
> > >> > https://github.com/apache/calcite/pull/2182 (enable error-prone
> > >> > verifications)
> > >>
> > >> I’m in favor it, but since it’s a large change (and therefore
> potential
> > >> for merge conflicts), timing will be important. Early in 1.27 is
> > probably
> > >> the best timing.
> > >>
> > >> Julian
> > >>
> > >>
> >
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Stamatis Zampetakis <za...@gmail.com>.
Hi Ruben,

If I remember well, you should commit them under CALCITE-4291 and then
proceed with the release.

Best,
Stamatis

On Fri, Oct 2, 2020 at 11:06 AM Ruben Q L <ru...@gmail.com> wrote:

> Hello,
>
> thanks everyone for your effort pushing the remaining issues forward.
> We enter a code freeze in order to generate a RC0 for 1.26.0, so please DO
> NOT commit into master until further notice.
>
> To our expert release managers, I have a stupid question about "how-to
> making a release candidate" instructions [1]:
> The changes that I need to "check" and "add" (README,
>  site/_docs/history.md, site/_docs/howto.md), do I need to commit those
> changes myself before starting the RC0 generation process; or I just need
> to make those changes locally, leave them uncommitted, because they will
> get automatically committed during the RC generation (or publication)
> process?
>
> Best regards,
> Ruben
>
> [1] https://calcite.apache.org/docs/howto.html#making-a-release-candidate
>
>
> On Thu, Oct 1, 2020 at 8:04 AM Ruben Q L <ru...@gmail.com> wrote:
>
> > FYI, AppVeyor issue has been resolved.
> > Thanks Julian and Vladimir for your help!
> >
> > On Wed, Sep 30, 2020 at 7:32 PM Julian Hyde <jh...@gmail.com>
> > wrote:
> >
> >>
> >>
> >> > PS. I wonder what everybody think of
> >> > https://github.com/apache/calcite/pull/2182 (enable error-prone
> >> > verifications)
> >>
> >> I’m in favor it, but since it’s a large change (and therefore potential
> >> for merge conflicts), timing will be important. Early in 1.27 is
> probably
> >> the best timing.
> >>
> >> Julian
> >>
> >>
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Hello,

thanks everyone for your effort pushing the remaining issues forward.
We enter a code freeze in order to generate a RC0 for 1.26.0, so please DO
NOT commit into master until further notice.

To our expert release managers, I have a stupid question about "how-to
making a release candidate" instructions [1]:
The changes that I need to "check" and "add" (README,
 site/_docs/history.md, site/_docs/howto.md), do I need to commit those
changes myself before starting the RC0 generation process; or I just need
to make those changes locally, leave them uncommitted, because they will
get automatically committed during the RC generation (or publication)
process?

Best regards,
Ruben

[1] https://calcite.apache.org/docs/howto.html#making-a-release-candidate


On Thu, Oct 1, 2020 at 8:04 AM Ruben Q L <ru...@gmail.com> wrote:

> FYI, AppVeyor issue has been resolved.
> Thanks Julian and Vladimir for your help!
>
> On Wed, Sep 30, 2020 at 7:32 PM Julian Hyde <jh...@gmail.com>
> wrote:
>
>>
>>
>> > PS. I wonder what everybody think of
>> > https://github.com/apache/calcite/pull/2182 (enable error-prone
>> > verifications)
>>
>> I’m in favor it, but since it’s a large change (and therefore potential
>> for merge conflicts), timing will be important. Early in 1.27 is probably
>> the best timing.
>>
>> Julian
>>
>>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
FYI, AppVeyor issue has been resolved.
Thanks Julian and Vladimir for your help!

On Wed, Sep 30, 2020 at 7:32 PM Julian Hyde <jh...@gmail.com> wrote:

>
>
> > PS. I wonder what everybody think of
> > https://github.com/apache/calcite/pull/2182 (enable error-prone
> > verifications)
>
> I’m in favor it, but since it’s a large change (and therefore potential
> for merge conflicts), timing will be important. Early in 1.27 is probably
> the best timing.
>
> Julian
>
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Julian Hyde <jh...@gmail.com>.

> PS. I wonder what everybody think of
> https://github.com/apache/calcite/pull/2182 (enable error-prone
> verifications)

I’m in favor it, but since it’s a large change (and therefore potential for merge conflicts), timing will be important. Early in 1.27 is probably the best timing.

Julian


Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Vladimir Sitnikov <si...@gmail.com>.
I can look into FmppTask.

PS. I wonder what everybody think of
https://github.com/apache/calcite/pull/2182 (enable error-prone
verifications)

Vladimir

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Hello everyone,

FYI, it seems that since the merge into master of CALCITE-4238 [1] (via
[2]), AppVeyor tests are failing systematically with the following error
[3]:

[00:03:17] Build calcite FAILURE reason:
[00:03:17]     Execution failed for task ':core:fmppMain':
[00:03:17]         : Failed to initialize FMPP engine.
[00:03:17]         Caused by: Failed to apply the value of the "data"
setting.
[00:03:17]
[00:03:17]         Caused by:
[00:03:17]         TDD syntax error: The + operator ("hash union") is
deprecated since FMPP 0.9.0, and starting from FMPP 0.9.9 it is not allowed
at all. Please use "hash addition" instead. For example, assuming that your
configuration file is in .properties format (same as .cfg), instead of this:
[00:03:17]         data={a:1, b:2} + properties(data/style.properties) +
birds:csv(data/birds.csv)
[00:03:17]         your should write this:
[00:03:17]         data=a:1, b:2, tdd(data/style.tdd),
birds:csv(data/birds.csv)
[00:03:17]         For more information on hash addition please see:
[00:03:17]         http://fmpp.sourceforge.net/tdd.html#hashAddition
[00:03:17]         Error location: line 1, column 25:
[00:03:17]         tdd(C:\projects\calcite +\core\src\main\codegen\confi...
[00:03:17]                                 ^
[00:03:17]             at fmpp.tools.AntTask.execute(AntTask.java:608)


The error does not occur with other CI environments. I have the impression
it might be related to FmppTask.kt [4].

I am not sure if this is a major issue that could jeopardize the release or
not (since it only appears on AppVeyor).
So far I have not been able to reproduce it in my local environment. I will
continue trying.
If someone with a bit more experience on FMPP / Kotlin could take a look, I
would appreciate it.

Best Regards,
Ruben

[1] https://issues.apache.org/jira/browse/CALCITE-4238
[2]
https://github.com/apache/calcite/commit/0b2dfb70dd9a97495283388a9edcbe2b12ddfec3
[3]
https://ci.appveyor.com/project/ApacheSoftwareFoundation/calcite/builds/35487356/job/t3mbcy7tk9o8o5a8#L110
[4]
https://github.com/apache/calcite/blob/539807bb0558890c2a92d0fc2af20c741a775fbc/buildSrc/subprojects/fmpp/src/main/kotlin/org/apache/calcite/buildtools/fmpp/FmppTask.kt#L66


On Wed, Sep 30, 2020 at 3:26 AM Danny Chan <yu...@gmail.com> wrote:

> The schedule sounds good to me, thanks Ruben for being the release manager
> ~
>
> Best,
> Danny Chan
> 在 2020年9月30日 +0800 AM3:44,Julian Hyde <jh...@gmail.com>,写道:
> > > What is the status on 4279 (SEARCH operator into Druid)?
> >
> > Working on it.
> >
> > > On Sep 29, 2020, at 11:58 AM, Ruben Q L <ru...@gmail.com> wrote:
> > >
> > > Thanks for the feedback, Julian.
> > > I will keep in mind changing 'MacOS' to 'macOS' in the release notes.
> > > What is the status on 4279 (SEARCH operator into Druid)?
> > >
> > > Ruben
> > >
> > >
> > >
> > > Le mar. 29 sept. 2020 à 19:51, Julian Hyde <jh...@gmail.com> a
> > > écrit :
> > >
> > > > Thursday sounds good.
> > > >
> > > > I am working on getting 3752 (PIVOT) and 4238 (parser configuration)
> > > > passing CI and merged. (4238 changes buildSrc and that seems to
> freak out
> > > > Gradle’s cache in CI.)
> > > >
> > > > For 4034 (InnoDB adapter), I am waiting for Xu (neoremind) to fix a
> > > > remaining bug. Don’t hold the release for 4034.
> > > >
> > > > As RM, can you please change ‘MacOS’ to ‘macOS’ (2 occurrences) when
> you
> > > > write the release notes. It got changed by accident last release.
> > > >
> > > > Julian
> > > >
> > > >
> > > > > On Sep 29, 2020, at 12:36 AM, Ruben Q L <ru...@gmail.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > things are moving forward, thanks everyone for pushing the pending
> issues
> > > > > into the release.
> > > > > There are still a few unresolved tickets [1], but most of them
> have a PR
> > > > > available and in good shape, so I think we can be reasonably
> optimistic.
> > > > > Would it sound feasible to get these final tickets resolved in the
> next
> > > > > couple of days and enter code freeze for master e.g. on Thursday
> night in
> > > > > order to have a first RC during the weekend?
> > > > >
> > > > > Best,
> > > > > Ruben
> > > > >
> > > > > [1]
> > > > >
> > > >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > > >
> > > > >
> > > > > Le ven. 25 sept. 2020 à 06:47, Chunwei Lei <ch...@gmail.com>
> a
> > > > > écrit :
> > > > >
> > > > > > Thank you for driving this, Ruben.
> > > > > >
> > > > > > The schedule looks good to me.
> > > > > >
> > > > > > Best,
> > > > > > Chunwei
> > > > > >
> > > > > >
> > > > > > On Thu, Sep 24, 2020 at 3:26 AM Rui Wang <am...@apache.org>
> wrote:
> > > > > >
> > > > > > > Thanks for all your help! Will experiment how it works best
> for me!
> > > > > > >
> > > > > > >
> > > > > > > -Rui
> > > > > > >
> > > > > > > On Wed, Sep 23, 2020 at 12:06 PM Ruben Q L <ru...@gmail.com>
> wrote:
> > > > > > >
> > > > > > > > Rui,
> > > > > > > > I am not a git expert, but what I usually do in these cases
> is
> > > > (working
> > > > > > > in
> > > > > > > > my local feature branch):
> > > > > > > > git rebase -i master
> > > > > > > > (editor will be opened, "pick" first commit, "squash" the
> rest; then
> > > > > > edit
> > > > > > > > your final squashed commit message)
> > > > > > > > Then you can force push. In your PR it should appear 1
> commit instead
> > > > > > of
> > > > > > > N.
> > > > > > > > This is just one way to do it, if you search online, you'll
> probably
> > > > > > find
> > > > > > > > better explanations than mine for this "git squash commits"
> operation.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Ruben
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Le mer. 23 sept. 2020 à 19:50, Julian Hyde <jh...@apache.org>
> a écrit
> > > > > > :
> > > > > > > >
> > > > > > > > > Feel free to experiment. If it creates a bad result - e.g.
> a merge
> > > > > > > > > commit, or does not squash - quickly back it out with a
> force push to
> > > > > > > > > master.
> > > > > > > > >
> > > > > > > > > Maybe I'm a git dinosaur, but I always use the command
> line to merge
> > > > > > > > > my own and others' changes. I don't trust the github UI to
> do exactly
> > > > > > > > > what I want.
> > > > > > > > >
> > > > > > > > > On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <
> amaliujia@apache.org>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Thanks Ruben for kicking off 1.26.0 release!
> > > > > > > > > >
> > > > > > > > > > Can I ask a question here: how can I squash commits to
> merge
> > > > > > > > > > https://github.com/apache/calcite/pull/2160? I am
> worried that if
> > > > > > I
> > > > > > > > > click
> > > > > > > > > > the "rebase and merge", it will push two commits into
> the Calcite
> > > > > > > main
> > > > > > > > > > branch.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -Rui
> > > > > > > > > >
> > > > > > > > > > On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <
> rubenql@gmail.com>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > It has been around one and a half months since our
> last release
> > > > > > > > > (1.25.0),
> > > > > > > > > > > and it seems a good moment to start discussing our
> next one
> > > > > > 1.26.0.
> > > > > > > > > > >
> > > > > > > > > > > As we can see in our Jira dashboard [1] there are a few
> > > > > > unresolved
> > > > > > > > > issues
> > > > > > > > > > > for 1.26.
> > > > > > > > > > > However, we have 180+ open pull requests [2], some of
> them seem
> > > > > > in
> > > > > > > > good
> > > > > > > > > > > shape, even though their corresponding Jira tickets do
> not
> > > > > > specify
> > > > > > > > > 1.26 as
> > > > > > > > > > > "fix version", so they do not appear in the Jira
> dashboard. I
> > > > > > > > encourage
> > > > > > > > > > > contributors to take a look at these open issues, in
> order to
> > > > > > > confirm
> > > > > > > > > what
> > > > > > > > > > > can / should be included in the next release.
> > > > > > > > > > >
> > > > > > > > > > > Ideally, I would like to generate a RC by the end of
> next week.
> > > > > > > > > > >
> > > > > > > > > > > Do not hesitate to reply to this thread if the plan
> above is not
> > > > > > > > > > > convenient for you.
> > > > > > > > > > >
> > > > > > > > > > > Best regards,
> > > > > > > > > > > Ruben
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > > > > > > > > > [2] https://github.com/apache/calcite/pulls
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > >
> >
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Danny Chan <yu...@gmail.com>.
The schedule sounds good to me, thanks Ruben for being the release manager ~

Best,
Danny Chan
在 2020年9月30日 +0800 AM3:44,Julian Hyde <jh...@gmail.com>,写道:
> > What is the status on 4279 (SEARCH operator into Druid)?
>
> Working on it.
>
> > On Sep 29, 2020, at 11:58 AM, Ruben Q L <ru...@gmail.com> wrote:
> >
> > Thanks for the feedback, Julian.
> > I will keep in mind changing 'MacOS' to 'macOS' in the release notes.
> > What is the status on 4279 (SEARCH operator into Druid)?
> >
> > Ruben
> >
> >
> >
> > Le mar. 29 sept. 2020 à 19:51, Julian Hyde <jh...@gmail.com> a
> > écrit :
> >
> > > Thursday sounds good.
> > >
> > > I am working on getting 3752 (PIVOT) and 4238 (parser configuration)
> > > passing CI and merged. (4238 changes buildSrc and that seems to freak out
> > > Gradle’s cache in CI.)
> > >
> > > For 4034 (InnoDB adapter), I am waiting for Xu (neoremind) to fix a
> > > remaining bug. Don’t hold the release for 4034.
> > >
> > > As RM, can you please change ‘MacOS’ to ‘macOS’ (2 occurrences) when you
> > > write the release notes. It got changed by accident last release.
> > >
> > > Julian
> > >
> > >
> > > > On Sep 29, 2020, at 12:36 AM, Ruben Q L <ru...@gmail.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > things are moving forward, thanks everyone for pushing the pending issues
> > > > into the release.
> > > > There are still a few unresolved tickets [1], but most of them have a PR
> > > > available and in good shape, so I think we can be reasonably optimistic.
> > > > Would it sound feasible to get these final tickets resolved in the next
> > > > couple of days and enter code freeze for master e.g. on Thursday night in
> > > > order to have a first RC during the weekend?
> > > >
> > > > Best,
> > > > Ruben
> > > >
> > > > [1]
> > > >
> > > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > >
> > > >
> > > > Le ven. 25 sept. 2020 à 06:47, Chunwei Lei <ch...@gmail.com> a
> > > > écrit :
> > > >
> > > > > Thank you for driving this, Ruben.
> > > > >
> > > > > The schedule looks good to me.
> > > > >
> > > > > Best,
> > > > > Chunwei
> > > > >
> > > > >
> > > > > On Thu, Sep 24, 2020 at 3:26 AM Rui Wang <am...@apache.org> wrote:
> > > > >
> > > > > > Thanks for all your help! Will experiment how it works best for me!
> > > > > >
> > > > > >
> > > > > > -Rui
> > > > > >
> > > > > > On Wed, Sep 23, 2020 at 12:06 PM Ruben Q L <ru...@gmail.com> wrote:
> > > > > >
> > > > > > > Rui,
> > > > > > > I am not a git expert, but what I usually do in these cases is
> > > (working
> > > > > > in
> > > > > > > my local feature branch):
> > > > > > > git rebase -i master
> > > > > > > (editor will be opened, "pick" first commit, "squash" the rest; then
> > > > > edit
> > > > > > > your final squashed commit message)
> > > > > > > Then you can force push. In your PR it should appear 1 commit instead
> > > > > of
> > > > > > N.
> > > > > > > This is just one way to do it, if you search online, you'll probably
> > > > > find
> > > > > > > better explanations than mine for this "git squash commits" operation.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Ruben
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Le mer. 23 sept. 2020 à 19:50, Julian Hyde <jh...@apache.org> a écrit
> > > > > :
> > > > > > >
> > > > > > > > Feel free to experiment. If it creates a bad result - e.g. a merge
> > > > > > > > commit, or does not squash - quickly back it out with a force push to
> > > > > > > > master.
> > > > > > > >
> > > > > > > > Maybe I'm a git dinosaur, but I always use the command line to merge
> > > > > > > > my own and others' changes. I don't trust the github UI to do exactly
> > > > > > > > what I want.
> > > > > > > >
> > > > > > > > On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <am...@apache.org>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Thanks Ruben for kicking off 1.26.0 release!
> > > > > > > > >
> > > > > > > > > Can I ask a question here: how can I squash commits to merge
> > > > > > > > > https://github.com/apache/calcite/pull/2160? I am worried that if
> > > > > I
> > > > > > > > click
> > > > > > > > > the "rebase and merge", it will push two commits into the Calcite
> > > > > > main
> > > > > > > > > branch.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > -Rui
> > > > > > > > >
> > > > > > > > > On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > It has been around one and a half months since our last release
> > > > > > > > (1.25.0),
> > > > > > > > > > and it seems a good moment to start discussing our next one
> > > > > 1.26.0.
> > > > > > > > > >
> > > > > > > > > > As we can see in our Jira dashboard [1] there are a few
> > > > > unresolved
> > > > > > > > issues
> > > > > > > > > > for 1.26.
> > > > > > > > > > However, we have 180+ open pull requests [2], some of them seem
> > > > > in
> > > > > > > good
> > > > > > > > > > shape, even though their corresponding Jira tickets do not
> > > > > specify
> > > > > > > > 1.26 as
> > > > > > > > > > "fix version", so they do not appear in the Jira dashboard. I
> > > > > > > encourage
> > > > > > > > > > contributors to take a look at these open issues, in order to
> > > > > > confirm
> > > > > > > > what
> > > > > > > > > > can / should be included in the next release.
> > > > > > > > > >
> > > > > > > > > > Ideally, I would like to generate a RC by the end of next week.
> > > > > > > > > >
> > > > > > > > > > Do not hesitate to reply to this thread if the plan above is not
> > > > > > > > > > convenient for you.
> > > > > > > > > >
> > > > > > > > > > Best regards,
> > > > > > > > > > Ruben
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > > > > > > > > [2] https://github.com/apache/calcite/pulls
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > >
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Julian Hyde <jh...@gmail.com>.
> What is the status on 4279 (SEARCH operator into Druid)?

Working on it.

> On Sep 29, 2020, at 11:58 AM, Ruben Q L <ru...@gmail.com> wrote:
> 
> Thanks for the feedback, Julian.
> I will keep in mind changing 'MacOS' to 'macOS' in the release notes.
> What is the status on 4279 (SEARCH operator into Druid)?
> 
> Ruben
> 
> 
> 
> Le mar. 29 sept. 2020 à 19:51, Julian Hyde <jh...@gmail.com> a
> écrit :
> 
>> Thursday sounds good.
>> 
>> I am working on getting 3752 (PIVOT) and 4238 (parser configuration)
>> passing CI and merged. (4238 changes buildSrc and that seems to freak out
>> Gradle’s cache in CI.)
>> 
>> For 4034 (InnoDB adapter), I am waiting for Xu (neoremind) to fix a
>> remaining bug. Don’t hold the release for 4034.
>> 
>> As RM, can you please change ‘MacOS’ to ‘macOS’ (2 occurrences) when you
>> write the release notes. It got changed by accident last release.
>> 
>> Julian
>> 
>> 
>>> On Sep 29, 2020, at 12:36 AM, Ruben Q L <ru...@gmail.com> wrote:
>>> 
>>> Hello,
>>> 
>>> things are moving forward, thanks everyone for pushing the pending issues
>>> into the release.
>>> There are still a few unresolved tickets [1], but most of them have a PR
>>> available and in good shape, so I think we can be reasonably optimistic.
>>> Would it sound feasible to get these final tickets resolved in the next
>>> couple of days and enter code freeze for master e.g. on Thursday night in
>>> order to have a first RC during the weekend?
>>> 
>>> Best,
>>> Ruben
>>> 
>>> [1]
>>> 
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>>> 
>>> 
>>> Le ven. 25 sept. 2020 à 06:47, Chunwei Lei <ch...@gmail.com> a
>>> écrit :
>>> 
>>>> Thank you for driving this, Ruben.
>>>> 
>>>> The schedule looks good to me.
>>>> 
>>>> Best,
>>>> Chunwei
>>>> 
>>>> 
>>>> On Thu, Sep 24, 2020 at 3:26 AM Rui Wang <am...@apache.org> wrote:
>>>> 
>>>>> Thanks for all your help! Will experiment how it works best for me!
>>>>> 
>>>>> 
>>>>> -Rui
>>>>> 
>>>>> On Wed, Sep 23, 2020 at 12:06 PM Ruben Q L <ru...@gmail.com> wrote:
>>>>> 
>>>>>> Rui,
>>>>>> I am not a git expert, but what I usually do in these cases is
>> (working
>>>>> in
>>>>>> my local feature branch):
>>>>>>   git rebase -i master
>>>>>> (editor will be opened, "pick" first commit, "squash" the rest; then
>>>> edit
>>>>>> your final squashed commit message)
>>>>>> Then you can force push. In your PR it should appear 1 commit instead
>>>> of
>>>>> N.
>>>>>> This is just one way to do it, if you search online, you'll probably
>>>> find
>>>>>> better explanations than mine for this "git squash commits" operation.
>>>>>> 
>>>>>> Best regards,
>>>>>> Ruben
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Le mer. 23 sept. 2020 à 19:50, Julian Hyde <jh...@apache.org> a écrit
>>>> :
>>>>>> 
>>>>>>> Feel free to experiment. If it creates a bad result - e.g. a merge
>>>>>>> commit, or does not squash - quickly back it out with a force push to
>>>>>>> master.
>>>>>>> 
>>>>>>> Maybe I'm a git dinosaur, but I always use the command line to merge
>>>>>>> my own and others' changes. I don't trust the github UI to do exactly
>>>>>>> what I want.
>>>>>>> 
>>>>>>> On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <am...@apache.org>
>>>>> wrote:
>>>>>>>> 
>>>>>>>> Thanks Ruben for kicking off 1.26.0 release!
>>>>>>>> 
>>>>>>>> Can I ask a question here: how can I squash commits to merge
>>>>>>>> https://github.com/apache/calcite/pull/2160? I am worried that if
>>>> I
>>>>>>> click
>>>>>>>> the "rebase and merge", it will push two commits into the Calcite
>>>>> main
>>>>>>>> branch.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -Rui
>>>>>>>> 
>>>>>>>> On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com>
>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi all,
>>>>>>>>> 
>>>>>>>>> It has been around one and a half months since our last release
>>>>>>> (1.25.0),
>>>>>>>>> and it seems a good moment to start discussing our next one
>>>> 1.26.0.
>>>>>>>>> 
>>>>>>>>> As we can see in our Jira dashboard [1] there are a few
>>>> unresolved
>>>>>>> issues
>>>>>>>>> for 1.26.
>>>>>>>>> However, we have 180+ open pull requests [2], some of them seem
>>>> in
>>>>>> good
>>>>>>>>> shape, even though their corresponding Jira tickets do not
>>>> specify
>>>>>>> 1.26 as
>>>>>>>>> "fix version", so they do not appear in the Jira dashboard. I
>>>>>> encourage
>>>>>>>>> contributors to take a look at these open issues, in order to
>>>>> confirm
>>>>>>> what
>>>>>>>>> can / should be included in the next release.
>>>>>>>>> 
>>>>>>>>> Ideally, I would like to generate a RC by the end of next week.
>>>>>>>>> 
>>>>>>>>> Do not hesitate to reply to this thread if the plan above is not
>>>>>>>>> convenient for you.
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> Ruben
>>>>>>>>> 
>>>>>>>>> [1]
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>>>>>>>>> [2] https://github.com/apache/calcite/pulls
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 


Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Thanks for the feedback, Julian.
I will keep in mind changing 'MacOS' to 'macOS' in the release notes.
What is the status on 4279 (SEARCH operator into Druid)?

Ruben



Le mar. 29 sept. 2020 à 19:51, Julian Hyde <jh...@gmail.com> a
écrit :

> Thursday sounds good.
>
> I am working on getting 3752 (PIVOT) and 4238 (parser configuration)
> passing CI and merged. (4238 changes buildSrc and that seems to freak out
> Gradle’s cache in CI.)
>
> For 4034 (InnoDB adapter), I am waiting for Xu (neoremind) to fix a
> remaining bug. Don’t hold the release for 4034.
>
> As RM, can you please change ‘MacOS’ to ‘macOS’ (2 occurrences) when you
> write the release notes. It got changed by accident last release.
>
> Julian
>
>
> > On Sep 29, 2020, at 12:36 AM, Ruben Q L <ru...@gmail.com> wrote:
> >
> > Hello,
> >
> > things are moving forward, thanks everyone for pushing the pending issues
> > into the release.
> > There are still a few unresolved tickets [1], but most of them have a PR
> > available and in good shape, so I think we can be reasonably optimistic.
> > Would it sound feasible to get these final tickets resolved in the next
> > couple of days and enter code freeze for master e.g. on Thursday night in
> > order to have a first RC during the weekend?
> >
> > Best,
> > Ruben
> >
> > [1]
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> >
> >
> > Le ven. 25 sept. 2020 à 06:47, Chunwei Lei <ch...@gmail.com> a
> > écrit :
> >
> >> Thank you for driving this, Ruben.
> >>
> >> The schedule looks good to me.
> >>
> >> Best,
> >> Chunwei
> >>
> >>
> >> On Thu, Sep 24, 2020 at 3:26 AM Rui Wang <am...@apache.org> wrote:
> >>
> >>> Thanks for all your help! Will experiment how it works best for me!
> >>>
> >>>
> >>> -Rui
> >>>
> >>> On Wed, Sep 23, 2020 at 12:06 PM Ruben Q L <ru...@gmail.com> wrote:
> >>>
> >>>> Rui,
> >>>> I am not a git expert, but what I usually do in these cases is
> (working
> >>> in
> >>>> my local feature branch):
> >>>>    git rebase -i master
> >>>> (editor will be opened, "pick" first commit, "squash" the rest; then
> >> edit
> >>>> your final squashed commit message)
> >>>> Then you can force push. In your PR it should appear 1 commit instead
> >> of
> >>> N.
> >>>> This is just one way to do it, if you search online, you'll probably
> >> find
> >>>> better explanations than mine for this "git squash commits" operation.
> >>>>
> >>>> Best regards,
> >>>> Ruben
> >>>>
> >>>>
> >>>>
> >>>> Le mer. 23 sept. 2020 à 19:50, Julian Hyde <jh...@apache.org> a écrit
> >> :
> >>>>
> >>>>> Feel free to experiment. If it creates a bad result - e.g. a merge
> >>>>> commit, or does not squash - quickly back it out with a force push to
> >>>>> master.
> >>>>>
> >>>>> Maybe I'm a git dinosaur, but I always use the command line to merge
> >>>>> my own and others' changes. I don't trust the github UI to do exactly
> >>>>> what I want.
> >>>>>
> >>>>> On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <am...@apache.org>
> >>> wrote:
> >>>>>>
> >>>>>> Thanks Ruben for kicking off 1.26.0 release!
> >>>>>>
> >>>>>> Can I ask a question here: how can I squash commits to merge
> >>>>>> https://github.com/apache/calcite/pull/2160? I am worried that if
> >> I
> >>>>> click
> >>>>>> the "rebase and merge", it will push two commits into the Calcite
> >>> main
> >>>>>> branch.
> >>>>>>
> >>>>>>
> >>>>>> -Rui
> >>>>>>
> >>>>>> On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> It has been around one and a half months since our last release
> >>>>> (1.25.0),
> >>>>>>> and it seems a good moment to start discussing our next one
> >> 1.26.0.
> >>>>>>>
> >>>>>>> As we can see in our Jira dashboard [1] there are a few
> >> unresolved
> >>>>> issues
> >>>>>>> for 1.26.
> >>>>>>> However, we have 180+ open pull requests [2], some of them seem
> >> in
> >>>> good
> >>>>>>> shape, even though their corresponding Jira tickets do not
> >> specify
> >>>>> 1.26 as
> >>>>>>> "fix version", so they do not appear in the Jira dashboard. I
> >>>> encourage
> >>>>>>> contributors to take a look at these open issues, in order to
> >>> confirm
> >>>>> what
> >>>>>>> can / should be included in the next release.
> >>>>>>>
> >>>>>>> Ideally, I would like to generate a RC by the end of next week.
> >>>>>>>
> >>>>>>> Do not hesitate to reply to this thread if the plan above is not
> >>>>>>> convenient for you.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Ruben
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> >>>>>>> [2] https://github.com/apache/calcite/pulls
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Julian Hyde <jh...@gmail.com>.
Thursday sounds good.

I am working on getting 3752 (PIVOT) and 4238 (parser configuration) passing CI and merged. (4238 changes buildSrc and that seems to freak out Gradle’s cache in CI.)

For 4034 (InnoDB adapter), I am waiting for Xu (neoremind) to fix a remaining bug. Don’t hold the release for 4034.

As RM, can you please change ‘MacOS’ to ‘macOS’ (2 occurrences) when you write the release notes. It got changed by accident last release.

Julian


> On Sep 29, 2020, at 12:36 AM, Ruben Q L <ru...@gmail.com> wrote:
> 
> Hello,
> 
> things are moving forward, thanks everyone for pushing the pending issues
> into the release.
> There are still a few unresolved tickets [1], but most of them have a PR
> available and in good shape, so I think we can be reasonably optimistic.
> Would it sound feasible to get these final tickets resolved in the next
> couple of days and enter code freeze for master e.g. on Thursday night in
> order to have a first RC during the weekend?
> 
> Best,
> Ruben
> 
> [1]
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> 
> 
> Le ven. 25 sept. 2020 à 06:47, Chunwei Lei <ch...@gmail.com> a
> écrit :
> 
>> Thank you for driving this, Ruben.
>> 
>> The schedule looks good to me.
>> 
>> Best,
>> Chunwei
>> 
>> 
>> On Thu, Sep 24, 2020 at 3:26 AM Rui Wang <am...@apache.org> wrote:
>> 
>>> Thanks for all your help! Will experiment how it works best for me!
>>> 
>>> 
>>> -Rui
>>> 
>>> On Wed, Sep 23, 2020 at 12:06 PM Ruben Q L <ru...@gmail.com> wrote:
>>> 
>>>> Rui,
>>>> I am not a git expert, but what I usually do in these cases is (working
>>> in
>>>> my local feature branch):
>>>>    git rebase -i master
>>>> (editor will be opened, "pick" first commit, "squash" the rest; then
>> edit
>>>> your final squashed commit message)
>>>> Then you can force push. In your PR it should appear 1 commit instead
>> of
>>> N.
>>>> This is just one way to do it, if you search online, you'll probably
>> find
>>>> better explanations than mine for this "git squash commits" operation.
>>>> 
>>>> Best regards,
>>>> Ruben
>>>> 
>>>> 
>>>> 
>>>> Le mer. 23 sept. 2020 à 19:50, Julian Hyde <jh...@apache.org> a écrit
>> :
>>>> 
>>>>> Feel free to experiment. If it creates a bad result - e.g. a merge
>>>>> commit, or does not squash - quickly back it out with a force push to
>>>>> master.
>>>>> 
>>>>> Maybe I'm a git dinosaur, but I always use the command line to merge
>>>>> my own and others' changes. I don't trust the github UI to do exactly
>>>>> what I want.
>>>>> 
>>>>> On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <am...@apache.org>
>>> wrote:
>>>>>> 
>>>>>> Thanks Ruben for kicking off 1.26.0 release!
>>>>>> 
>>>>>> Can I ask a question here: how can I squash commits to merge
>>>>>> https://github.com/apache/calcite/pull/2160? I am worried that if
>> I
>>>>> click
>>>>>> the "rebase and merge", it will push two commits into the Calcite
>>> main
>>>>>> branch.
>>>>>> 
>>>>>> 
>>>>>> -Rui
>>>>>> 
>>>>>> On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com>
>>> wrote:
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> It has been around one and a half months since our last release
>>>>> (1.25.0),
>>>>>>> and it seems a good moment to start discussing our next one
>> 1.26.0.
>>>>>>> 
>>>>>>> As we can see in our Jira dashboard [1] there are a few
>> unresolved
>>>>> issues
>>>>>>> for 1.26.
>>>>>>> However, we have 180+ open pull requests [2], some of them seem
>> in
>>>> good
>>>>>>> shape, even though their corresponding Jira tickets do not
>> specify
>>>>> 1.26 as
>>>>>>> "fix version", so they do not appear in the Jira dashboard. I
>>>> encourage
>>>>>>> contributors to take a look at these open issues, in order to
>>> confirm
>>>>> what
>>>>>>> can / should be included in the next release.
>>>>>>> 
>>>>>>> Ideally, I would like to generate a RC by the end of next week.
>>>>>>> 
>>>>>>> Do not hesitate to reply to this thread if the plan above is not
>>>>>>> convenient for you.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Ruben
>>>>>>> 
>>>>>>> [1]
>>>>>>> 
>>>>> 
>>>> 
>>> 
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
>>>>>>> [2] https://github.com/apache/calcite/pulls
>>>>>>> 
>>>>> 
>>>> 
>>> 
>> 


Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Hello,

things are moving forward, thanks everyone for pushing the pending issues
into the release.
There are still a few unresolved tickets [1], but most of them have a PR
available and in good shape, so I think we can be reasonably optimistic.
Would it sound feasible to get these final tickets resolved in the next
couple of days and enter code freeze for master e.g. on Thursday night in
order to have a first RC during the weekend?

Best,
Ruben

[1]
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950


Le ven. 25 sept. 2020 à 06:47, Chunwei Lei <ch...@gmail.com> a
écrit :

> Thank you for driving this, Ruben.
>
> The schedule looks good to me.
>
> Best,
> Chunwei
>
>
> On Thu, Sep 24, 2020 at 3:26 AM Rui Wang <am...@apache.org> wrote:
>
> > Thanks for all your help! Will experiment how it works best for me!
> >
> >
> > -Rui
> >
> > On Wed, Sep 23, 2020 at 12:06 PM Ruben Q L <ru...@gmail.com> wrote:
> >
> > > Rui,
> > > I am not a git expert, but what I usually do in these cases is (working
> > in
> > > my local feature branch):
> > >     git rebase -i master
> > > (editor will be opened, "pick" first commit, "squash" the rest; then
> edit
> > > your final squashed commit message)
> > > Then you can force push. In your PR it should appear 1 commit instead
> of
> > N.
> > > This is just one way to do it, if you search online, you'll probably
> find
> > > better explanations than mine for this "git squash commits" operation.
> > >
> > > Best regards,
> > > Ruben
> > >
> > >
> > >
> > > Le mer. 23 sept. 2020 à 19:50, Julian Hyde <jh...@apache.org> a écrit
> :
> > >
> > > > Feel free to experiment. If it creates a bad result - e.g. a merge
> > > > commit, or does not squash - quickly back it out with a force push to
> > > > master.
> > > >
> > > > Maybe I'm a git dinosaur, but I always use the command line to merge
> > > > my own and others' changes. I don't trust the github UI to do exactly
> > > > what I want.
> > > >
> > > > On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <am...@apache.org>
> > wrote:
> > > > >
> > > > > Thanks Ruben for kicking off 1.26.0 release!
> > > > >
> > > > > Can I ask a question here: how can I squash commits to merge
> > > > > https://github.com/apache/calcite/pull/2160? I am worried that if
> I
> > > > click
> > > > > the "rebase and merge", it will push two commits into the Calcite
> > main
> > > > > branch.
> > > > >
> > > > >
> > > > > -Rui
> > > > >
> > > > > On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com>
> > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > It has been around one and a half months since our last release
> > > > (1.25.0),
> > > > > > and it seems a good moment to start discussing our next one
> 1.26.0.
> > > > > >
> > > > > > As we can see in our Jira dashboard [1] there are a few
> unresolved
> > > > issues
> > > > > > for 1.26.
> > > > > > However, we have 180+ open pull requests [2], some of them seem
> in
> > > good
> > > > > > shape, even though their corresponding Jira tickets do not
> specify
> > > > 1.26 as
> > > > > > "fix version", so they do not appear in the Jira dashboard. I
> > > encourage
> > > > > > contributors to take a look at these open issues, in order to
> > confirm
> > > > what
> > > > > > can / should be included in the next release.
> > > > > >
> > > > > > Ideally, I would like to generate a RC by the end of next week.
> > > > > >
> > > > > > Do not hesitate to reply to this thread if the plan above is not
> > > > > > convenient for you.
> > > > > >
> > > > > > Best regards,
> > > > > > Ruben
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > > > > [2] https://github.com/apache/calcite/pulls
> > > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Chunwei Lei <ch...@gmail.com>.
Thank you for driving this, Ruben.

The schedule looks good to me.

Best,
Chunwei


On Thu, Sep 24, 2020 at 3:26 AM Rui Wang <am...@apache.org> wrote:

> Thanks for all your help! Will experiment how it works best for me!
>
>
> -Rui
>
> On Wed, Sep 23, 2020 at 12:06 PM Ruben Q L <ru...@gmail.com> wrote:
>
> > Rui,
> > I am not a git expert, but what I usually do in these cases is (working
> in
> > my local feature branch):
> >     git rebase -i master
> > (editor will be opened, "pick" first commit, "squash" the rest; then edit
> > your final squashed commit message)
> > Then you can force push. In your PR it should appear 1 commit instead of
> N.
> > This is just one way to do it, if you search online, you'll probably find
> > better explanations than mine for this "git squash commits" operation.
> >
> > Best regards,
> > Ruben
> >
> >
> >
> > Le mer. 23 sept. 2020 à 19:50, Julian Hyde <jh...@apache.org> a écrit :
> >
> > > Feel free to experiment. If it creates a bad result - e.g. a merge
> > > commit, or does not squash - quickly back it out with a force push to
> > > master.
> > >
> > > Maybe I'm a git dinosaur, but I always use the command line to merge
> > > my own and others' changes. I don't trust the github UI to do exactly
> > > what I want.
> > >
> > > On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <am...@apache.org>
> wrote:
> > > >
> > > > Thanks Ruben for kicking off 1.26.0 release!
> > > >
> > > > Can I ask a question here: how can I squash commits to merge
> > > > https://github.com/apache/calcite/pull/2160? I am worried that if I
> > > click
> > > > the "rebase and merge", it will push two commits into the Calcite
> main
> > > > branch.
> > > >
> > > >
> > > > -Rui
> > > >
> > > > On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com>
> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > It has been around one and a half months since our last release
> > > (1.25.0),
> > > > > and it seems a good moment to start discussing our next one 1.26.0.
> > > > >
> > > > > As we can see in our Jira dashboard [1] there are a few unresolved
> > > issues
> > > > > for 1.26.
> > > > > However, we have 180+ open pull requests [2], some of them seem in
> > good
> > > > > shape, even though their corresponding Jira tickets do not specify
> > > 1.26 as
> > > > > "fix version", so they do not appear in the Jira dashboard. I
> > encourage
> > > > > contributors to take a look at these open issues, in order to
> confirm
> > > what
> > > > > can / should be included in the next release.
> > > > >
> > > > > Ideally, I would like to generate a RC by the end of next week.
> > > > >
> > > > > Do not hesitate to reply to this thread if the plan above is not
> > > > > convenient for you.
> > > > >
> > > > > Best regards,
> > > > > Ruben
> > > > >
> > > > > [1]
> > > > >
> > >
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > > > [2] https://github.com/apache/calcite/pulls
> > > > >
> > >
> >
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Rui Wang <am...@apache.org>.
Thanks for all your help! Will experiment how it works best for me!


-Rui

On Wed, Sep 23, 2020 at 12:06 PM Ruben Q L <ru...@gmail.com> wrote:

> Rui,
> I am not a git expert, but what I usually do in these cases is (working in
> my local feature branch):
>     git rebase -i master
> (editor will be opened, "pick" first commit, "squash" the rest; then edit
> your final squashed commit message)
> Then you can force push. In your PR it should appear 1 commit instead of N.
> This is just one way to do it, if you search online, you'll probably find
> better explanations than mine for this "git squash commits" operation.
>
> Best regards,
> Ruben
>
>
>
> Le mer. 23 sept. 2020 à 19:50, Julian Hyde <jh...@apache.org> a écrit :
>
> > Feel free to experiment. If it creates a bad result - e.g. a merge
> > commit, or does not squash - quickly back it out with a force push to
> > master.
> >
> > Maybe I'm a git dinosaur, but I always use the command line to merge
> > my own and others' changes. I don't trust the github UI to do exactly
> > what I want.
> >
> > On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <am...@apache.org> wrote:
> > >
> > > Thanks Ruben for kicking off 1.26.0 release!
> > >
> > > Can I ask a question here: how can I squash commits to merge
> > > https://github.com/apache/calcite/pull/2160? I am worried that if I
> > click
> > > the "rebase and merge", it will push two commits into the Calcite main
> > > branch.
> > >
> > >
> > > -Rui
> > >
> > > On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > It has been around one and a half months since our last release
> > (1.25.0),
> > > > and it seems a good moment to start discussing our next one 1.26.0.
> > > >
> > > > As we can see in our Jira dashboard [1] there are a few unresolved
> > issues
> > > > for 1.26.
> > > > However, we have 180+ open pull requests [2], some of them seem in
> good
> > > > shape, even though their corresponding Jira tickets do not specify
> > 1.26 as
> > > > "fix version", so they do not appear in the Jira dashboard. I
> encourage
> > > > contributors to take a look at these open issues, in order to confirm
> > what
> > > > can / should be included in the next release.
> > > >
> > > > Ideally, I would like to generate a RC by the end of next week.
> > > >
> > > > Do not hesitate to reply to this thread if the plan above is not
> > > > convenient for you.
> > > >
> > > > Best regards,
> > > > Ruben
> > > >
> > > > [1]
> > > >
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > > [2] https://github.com/apache/calcite/pulls
> > > >
> >
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Ruben Q L <ru...@gmail.com>.
Rui,
I am not a git expert, but what I usually do in these cases is (working in
my local feature branch):
    git rebase -i master
(editor will be opened, "pick" first commit, "squash" the rest; then edit
your final squashed commit message)
Then you can force push. In your PR it should appear 1 commit instead of N.
This is just one way to do it, if you search online, you'll probably find
better explanations than mine for this "git squash commits" operation.

Best regards,
Ruben



Le mer. 23 sept. 2020 à 19:50, Julian Hyde <jh...@apache.org> a écrit :

> Feel free to experiment. If it creates a bad result - e.g. a merge
> commit, or does not squash - quickly back it out with a force push to
> master.
>
> Maybe I'm a git dinosaur, but I always use the command line to merge
> my own and others' changes. I don't trust the github UI to do exactly
> what I want.
>
> On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <am...@apache.org> wrote:
> >
> > Thanks Ruben for kicking off 1.26.0 release!
> >
> > Can I ask a question here: how can I squash commits to merge
> > https://github.com/apache/calcite/pull/2160? I am worried that if I
> click
> > the "rebase and merge", it will push two commits into the Calcite main
> > branch.
> >
> >
> > -Rui
> >
> > On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > It has been around one and a half months since our last release
> (1.25.0),
> > > and it seems a good moment to start discussing our next one 1.26.0.
> > >
> > > As we can see in our Jira dashboard [1] there are a few unresolved
> issues
> > > for 1.26.
> > > However, we have 180+ open pull requests [2], some of them seem in good
> > > shape, even though their corresponding Jira tickets do not specify
> 1.26 as
> > > "fix version", so they do not appear in the Jira dashboard. I encourage
> > > contributors to take a look at these open issues, in order to confirm
> what
> > > can / should be included in the next release.
> > >
> > > Ideally, I would like to generate a RC by the end of next week.
> > >
> > > Do not hesitate to reply to this thread if the plan above is not
> > > convenient for you.
> > >
> > > Best regards,
> > > Ruben
> > >
> > > [1]
> > >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > > [2] https://github.com/apache/calcite/pulls
> > >
>

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Julian Hyde <jh...@apache.org>.
Feel free to experiment. If it creates a bad result - e.g. a merge
commit, or does not squash - quickly back it out with a force push to
master.

Maybe I'm a git dinosaur, but I always use the command line to merge
my own and others' changes. I don't trust the github UI to do exactly
what I want.

On Wed, Sep 23, 2020 at 11:45 AM Rui Wang <am...@apache.org> wrote:
>
> Thanks Ruben for kicking off 1.26.0 release!
>
> Can I ask a question here: how can I squash commits to merge
> https://github.com/apache/calcite/pull/2160? I am worried that if I click
> the "rebase and merge", it will push two commits into the Calcite main
> branch.
>
>
> -Rui
>
> On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com> wrote:
>
> > Hi all,
> >
> > It has been around one and a half months since our last release (1.25.0),
> > and it seems a good moment to start discussing our next one 1.26.0.
> >
> > As we can see in our Jira dashboard [1] there are a few unresolved issues
> > for 1.26.
> > However, we have 180+ open pull requests [2], some of them seem in good
> > shape, even though their corresponding Jira tickets do not specify 1.26 as
> > "fix version", so they do not appear in the Jira dashboard. I encourage
> > contributors to take a look at these open issues, in order to confirm what
> > can / should be included in the next release.
> >
> > Ideally, I would like to generate a RC by the end of next week.
> >
> > Do not hesitate to reply to this thread if the plan above is not
> > convenient for you.
> >
> > Best regards,
> > Ruben
> >
> > [1]
> > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> > [2] https://github.com/apache/calcite/pulls
> >

Re: [DISCUSS] Towards Calcite 1.26.0

Posted by Rui Wang <am...@apache.org>.
Thanks Ruben for kicking off 1.26.0 release!

Can I ask a question here: how can I squash commits to merge
https://github.com/apache/calcite/pull/2160? I am worried that if I click
the "rebase and merge", it will push two commits into the Calcite main
branch.


-Rui

On Wed, Sep 23, 2020 at 11:38 AM Ruben Q L <ru...@gmail.com> wrote:

> Hi all,
>
> It has been around one and a half months since our last release (1.25.0),
> and it seems a good moment to start discussing our next one 1.26.0.
>
> As we can see in our Jira dashboard [1] there are a few unresolved issues
> for 1.26.
> However, we have 180+ open pull requests [2], some of them seem in good
> shape, even though their corresponding Jira tickets do not specify 1.26 as
> "fix version", so they do not appear in the Jira dashboard. I encourage
> contributors to take a look at these open issues, in order to confirm what
> can / should be included in the next release.
>
> Ideally, I would like to generate a RC by the end of next week.
>
> Do not hesitate to reply to this thread if the plan above is not
> convenient for you.
>
> Best regards,
> Ruben
>
> [1]
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
> [2] https://github.com/apache/calcite/pulls
>