[jira] [Created] (CALCITE-4176) Key descriptor can be optional in SESSION table function

[Rui Wang (Jira)]

Rui Wang created CALCITE-4176:
-

 Summary: Key descriptor can be optional in SESSION table function
 Key: CALCITE-4176
 URL: https://issues.apache.org/jira/browse/CALCITE-4176
 Project: Calcite
  Issue Type: Sub-task
Reporter: Rui Wang
Assignee: Rui Wang






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Open SVN dist access to committers

[Chunwei Lei]

Awesome! It really helps for the committers as release manager.

Best,
Chunwei


On Fri, Aug 14, 2020 at 6:58 AM Julian Hyde  wrote:

> Thanks for the clarification, Sebb. We now know, and accept, that the risk
> is non-zero.
>
> > On Aug 13, 2020, at 2:17 PM, sebbaz  wrote:
> >
> >
> >
> > On 2020/08/13 18:47:54, Julian Hyde  wrote:
> >> +1
> >>
> >> Clearly committers should have read and write access to all non-private
> information in a project. I don’t even think this needs a vote. If this
> discussion quickly reaches consensus, as I assume it will, let’s just make
> it so.
> >>
> >> The hypothetical risk that a committer would (accidentally or
> deliberately) cause damage is a non-issue. In source control systems such
> as SVN or Git, any change can be rolled back.
> >
> > Please note that the dist.apache.org release directory is very
> different in this regard.
> >
> > If artifacts are published by moving them to the release directory, it
> is *not* easily possible to revert publication
> >
> > This is because the release directory is used to distribute the files to
> the world-wide mirror system.
> > And to the ASF archive system, which would require Infra assistance to
> revert.
> >
> > Mistakes are not easily recovered.
> >
> > This is why the default is for PMC members only.
> >
> >> Julian
> >>
> >>
> >>> On Aug 13, 2020, at 8:07 AM, Andrei Sereda  wrote:
> >>>
> >>> Hello,
> >>>
> >>> For the last two releases ([1] and [2]) committers were not able to
> >>> finalize the release due to SVN restrictions. One of the PMC members
> had to
> >>> step in order to distribute the artifacts.
> >>>
> >>> By default, only PMCs are allowed to make changes to dist
> >>>  SVN repository.
> >>>
> >>> This can be changed
> >>> <
> https://issues.apache.org/jira/browse/INFRA-20681?focusedCommentId=17177075&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17177075
> >.
> >>> According to INFA:
> >>>
>  A link on this Jira to an email discussion where it is approved will
> be
> >>> fine
> >>>
> >>> PMCs please vote on this proposal.
> >>>
> >>> Thanks,
> >>> Andrei.
> >>>
> >>> [1]
> >>>
> https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E
> >>> [2]
> >>>
> https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E
> >>
> >>
>
>

[jira] [Created] (CALCITE-4175) Add ability to create a connection and DSN from a Config

[Josiah Goodson (Jira)]

Josiah Goodson created CALCITE-4175:
---

 Summary: Add ability to create a connection and DSN from a Config
 Key: CALCITE-4175
 URL: https://issues.apache.org/jira/browse/CALCITE-4175
 Project: Calcite
  Issue Type: Improvement
  Components: avatica-go
Reporter: Josiah Goodson
Assignee: Francis Chuang


Currently the avatica-go driver requires the user to specify a DSN to open 
connections. A config is then generated from this DSN.

Other similar projects 
([go-sql-driver/mysql|https://godoc.org/github.com/go-sql-driver/mysql#Config.FormatDSN])
 allow you to create a DSN from a config supplied in a struct.

This issue covers the ability to create a connection and DSN from a Config



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Release Managers

[Haisheng Yuan]

Thanks for volunteering, Ruben! I think you can be the release manager for 
1.26.0.

We still need 2 more volunteers for the next 2 versions.

Thanks,
Haisheng

On 2020/07/25 15:24:43, Ruben Q L  wrote: 
> Hi,
> 
> I can volunteer for one of them, for example 1.26.0
> 
> Best regards,
> Ruben
> 
> 
> Le sam. 25 juil. 2020 à 15:23, Haisheng Yuan  a écrit :
> 
> > Hi,
> >
> > Would anyone be interested in being release manager for v1.26.0, v1.27.0
> > or v1.28.0?
> > We need 3 volunteers (must be PMC or committer) for these 3 versions.
> >
> > Thanks,
> > Haisheng Yuan
> >
> 

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

[Julian Hyde]

Since the release vote has passed, Andrei as release manager can declare the 
master branch open for commits. Publishing the artifacts and making the release 
announcement can go on in parallel.

> On Aug 13, 2020, at 3:37 PM, Andrei Sereda  wrote:
> 
> Hi Haisheng,
> 
> Thanks for your reply.
> 
> There is a parallel discussion [1] about letting committers have write
> access to SVN dist repository. Seems like most people are on the same page
> (ie +1).
> If approved, I should be able to finalize the release soon myself.
> 
> Andrei.
> 
> 
> [1]
> https://lists.apache.org/thread.html/raf959fc1e4e5d143ce220589de9cb798c51d39b9e1faf4b682bda9ba%40%3Cdev.calcite.apache.org%3E
> 
> 
> On Thu, Aug 13, 2020 at 6:02 PM Haisheng Yuan  wrote:
> 
>> Hi Andrei,
>> 
>> Let's unblock the release as soon as possible.
>> I can help publish the artifact.
>> 
>> Can you cat build/stagingRepositories/nexus.txt and send me the content in
>> your local repo?
>> 
>> Thanks,
>> Haisheng
>> 
>> On 2020/08/13 14:47:05, Andrei Sereda  wrote:
>>> It can also be configured per project.
>>> 
 Do you know if SVN access can be configured per project ?
 Yes it can, if the PMC agrees to it, the dist area can be opened up to
>>> all project committers - a few PMCs have done this.
>>> 
>>> On Thu, Aug 13, 2020 at 10:43 AM Andrei Sereda  wrote:
>>> 
 Inquired with INFRA-20681
  seems like only
>> PMCs
 can commit to dist SVN:
 
> Are committers (which are not PMCs) allowed to commit to SVN dist
>> repo ?
> ..., nope, by default its PMC members only
 
 
 
 On Thu, Aug 13, 2020 at 9:27 AM Andrei Sereda 
>> wrote:
 
> Can someone from PMC pls publish the release ?  Or maybe contact INFRA
> about svn permissions for committers vs PMCs ?
> 
> I would like to avoid blocking calcite development for too long.
> 
> 
> On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei 
> wrote:
> 
>>> Once this release is done, we should consider whether we should
>> give
>> committers write access to SVN to avoid these issues in the future.
>> I am
>> not sure if this is possible or if this is just the way ASF's infra
>> is
>> set up, but it's worth a look.
>> 
>> I cannot agree more. Thank you for pointing out, Francis.
>> (We can add some notes about it at least~~)
>> 
>> 
>> 
>> Best,
>> Chunwei
>> 
>> 
>> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang <
>> francischu...@apache.org>
>> wrote:
>> 
>>> Can someone please push the release artifacts for Andrei? I believe
>> this
>>> is the same issue we had with the last release, where the RM is
>> not a
>>> PMC member and doesn't have write access to SVN [1].
>>> 
>>> Once this release is done, we should consider whether we should
>> give
>>> committers write access to SVN to avoid these issues in the
>> future. I
>> am
>>> not sure if this is possible or if this is just the way ASF's
>> infra is
>>> set up, but it's worth a look.
>>> 
>>> Francis
>>> 
>>> [1]
>>> 
>>> 
>> 
>> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
>>> 
>>> On 13/08/2020 8:51 am, Andrei Sereda wrote:
 Thanks, Stamatis. All seems to be working now.
 
 On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis <
>> zabe...@gmail.com>
 wrote:
 
> Hi Andrei,
> 
> I uploaded your key to the file. Please check.
> 
> Normally you don't need to be in the PMC to have access to the
>> svn
>> repo.
> I don't know what went wrong and you were not able to push it
>> through.
> 
> Best,
> Stamatis
> 
> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda >> 
>> wrote:
> 
>> Hello,
>> 
>> Can somebody from PMC pls upload my public GPG key to KEYS
>>  ? I
>> don't
>>> have
>> permissions for that svn repo.
>> 
>> I've sent an email to priv...@calcite.apache.org.
>> 
>> Thanks,
>> Andrei.
>> 
>> On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda >> 
>>> wrote:
>> 
>>> Hi All,
>>> 
>>> I plan to close the vote tomorrow (Aug 12th). If you still
>> want to
>>> validate RC0 please do so before Wednesday.
>>> 
>>> Regards,
>>> Andrei.
>>> 
>>> On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda
>> 
> wrote:
>>> 
 Thanks, Julian, for the hint. I'll update the KEYS file.
 
 On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde <
>> jhyde.apa...@gmail.com
 
 wrote:
 
>>

Re: [DISCUSS] Open SVN dist access to committers

[Julian Hyde]

Thanks for the clarification, Sebb. We now know, and accept, that the risk is 
non-zero.

> On Aug 13, 2020, at 2:17 PM, sebbaz  wrote:
> 
> 
> 
> On 2020/08/13 18:47:54, Julian Hyde  wrote: 
>> +1
>> 
>> Clearly committers should have read and write access to all non-private 
>> information in a project. I don’t even think this needs a vote. If this 
>> discussion quickly reaches consensus, as I assume it will, let’s just make 
>> it so.
>> 
>> The hypothetical risk that a committer would (accidentally or deliberately) 
>> cause damage is a non-issue. In source control systems such as SVN or Git, 
>> any change can be rolled back.
> 
> Please note that the dist.apache.org release directory is very different in 
> this regard.
> 
> If artifacts are published by moving them to the release directory, it is 
> *not* easily possible to revert publication
> 
> This is because the release directory is used to distribute the files to the 
> world-wide mirror system.
> And to the ASF archive system, which would require Infra assistance to revert.
> 
> Mistakes are not easily recovered.
> 
> This is why the default is for PMC members only.
> 
>> Julian
>> 
>> 
>>> On Aug 13, 2020, at 8:07 AM, Andrei Sereda  wrote:
>>> 
>>> Hello,
>>> 
>>> For the last two releases ([1] and [2]) committers were not able to
>>> finalize the release due to SVN restrictions. One of the PMC members had to
>>> step in order to distribute the artifacts.
>>> 
>>> By default, only PMCs are allowed to make changes to dist
>>>  SVN repository.
>>> 
>>> This can be changed
>>> .
>>> According to INFA:
>>> 
 A link on this Jira to an email discussion where it is approved will be
>>> fine
>>> 
>>> PMCs please vote on this proposal.
>>> 
>>> Thanks,
>>> Andrei.
>>> 
>>> [1]
>>> https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E
>>> [2]
>>> https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E
>> 
>> 

Re: [DISCUSS] Open SVN dist access to committers

[Francis Chuang]

+1 from me as well. From our side, the risk is minimized as the process 
to move the artifacts on SVN is automated using Vladimir's gradle 
plugin, so there shouldn't be any manual intervention on the part of the RM.


Francis

On 14/08/2020 8:34 am, Ruben Q L wrote:

+1

Apart from the reasons already mentioned, if we want committers (not just
PMC) to get involved in the release management process, I think this step
would go in the right direction.

Best regards,
Ruben


Le jeu. 13 août 2020 à 23:18, Rui Wang  a écrit :


+1

if well used/tested svn commands for releasing are documented, committers
without experience on release or svn can still use those properly.


-Rui

On Thu, Aug 13, 2020 at 3:09 PM Stamatis Zampetakis 
wrote:


+1

I always thought that committers had access to the dist repo and I was
completely fine with it.

Everybody makes mistakes no matter if it is a committer or PMC so I don't
see a reason to have different read/write access to the repo.

Best,
Stamatis

On Fri, Aug 14, 2020 at 12:17 AM sebbaz  wrote:




On 2020/08/13 18:47:54, Julian Hyde  wrote:

+1

Clearly committers should have read and write access to all

non-private

information in a project. I don’t even think this needs a vote. If this
discussion quickly reaches consensus, as I assume it will, let’s just

make

it so.


The hypothetical risk that a committer would (accidentally or

deliberately) cause damage is a non-issue. In source control systems

such

as SVN or Git, any change can be rolled back.

Please note that the dist.apache.org release directory is very

different

in this regard.

If artifacts are published by moving them to the release directory, it

is

*not* easily possible to revert publication

This is because the release directory is used to distribute the files

to

the world-wide mirror system.
And to the ASF archive system, which would require Infra assistance to
revert.

Mistakes are not easily recovered.

This is why the default is for PMC members only.


Julian



On Aug 13, 2020, at 8:07 AM, Andrei Sereda 

wrote:


Hello,

For the last two releases ([1] and [2]) committers were not able to
finalize the release due to SVN restrictions. One of the PMC

members

had to

step in order to distribute the artifacts.

By default, only PMCs are allowed to make changes to dist
 SVN

repository.


This can be changed
<





https://issues.apache.org/jira/browse/INFRA-20681?focusedCommentId=17177075&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17177075

.

According to INFA:


A link on this Jira to an email discussion where it is approved

will

be

fine

PMCs please vote on this proposal.

Thanks,
Andrei.

[1]






https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E

[2]






https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

[Andrei Sereda]

Hi Haisheng,

Thanks for your reply.

There is a parallel discussion [1] about letting committers have write
access to SVN dist repository. Seems like most people are on the same page
(ie +1).
If approved, I should be able to finalize the release soon myself.

Andrei.


[1]
https://lists.apache.org/thread.html/raf959fc1e4e5d143ce220589de9cb798c51d39b9e1faf4b682bda9ba%40%3Cdev.calcite.apache.org%3E


On Thu, Aug 13, 2020 at 6:02 PM Haisheng Yuan  wrote:

> Hi Andrei,
>
> Let's unblock the release as soon as possible.
> I can help publish the artifact.
>
> Can you cat build/stagingRepositories/nexus.txt and send me the content in
> your local repo?
>
> Thanks,
> Haisheng
>
> On 2020/08/13 14:47:05, Andrei Sereda  wrote:
> > It can also be configured per project.
> >
> > > Do you know if SVN access can be configured per project ?
> > > Yes it can, if the PMC agrees to it, the dist area can be opened up to
> > all project committers - a few PMCs have done this.
> >
> > On Thu, Aug 13, 2020 at 10:43 AM Andrei Sereda  wrote:
> >
> > > Inquired with INFRA-20681
> > >  seems like only
> PMCs
> > > can commit to dist SVN:
> > >
> > > > Are committers (which are not PMCs) allowed to commit to SVN dist
> repo ?
> > > > ..., nope, by default its PMC members only
> > >
> > >
> > >
> > > On Thu, Aug 13, 2020 at 9:27 AM Andrei Sereda 
> wrote:
> > >
> > >> Can someone from PMC pls publish the release ?  Or maybe contact INFRA
> > >> about svn permissions for committers vs PMCs ?
> > >>
> > >> I would like to avoid blocking calcite development for too long.
> > >>
> > >>
> > >> On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei 
> > >> wrote:
> > >>
> > >>> > Once this release is done, we should consider whether we should
> give
> > >>> committers write access to SVN to avoid these issues in the future.
> I am
> > >>> not sure if this is possible or if this is just the way ASF's infra
> is
> > >>> set up, but it's worth a look.
> > >>>
> > >>> I cannot agree more. Thank you for pointing out, Francis.
> > >>> (We can add some notes about it at least~~)
> > >>>
> > >>>
> > >>>
> > >>> Best,
> > >>> Chunwei
> > >>>
> > >>>
> > >>> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang <
> > >>> francischu...@apache.org>
> > >>> wrote:
> > >>>
> > >>> > Can someone please push the release artifacts for Andrei? I believe
> > >>> this
> > >>> > is the same issue we had with the last release, where the RM is
> not a
> > >>> > PMC member and doesn't have write access to SVN [1].
> > >>> >
> > >>> > Once this release is done, we should consider whether we should
> give
> > >>> > committers write access to SVN to avoid these issues in the
> future. I
> > >>> am
> > >>> > not sure if this is possible or if this is just the way ASF's
> infra is
> > >>> > set up, but it's worth a look.
> > >>> >
> > >>> > Francis
> > >>> >
> > >>> > [1]
> > >>> >
> > >>> >
> > >>>
> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
> > >>> >
> > >>> > On 13/08/2020 8:51 am, Andrei Sereda wrote:
> > >>> > > Thanks, Stamatis. All seems to be working now.
> > >>> > >
> > >>> > > On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis <
> > >>> zabe...@gmail.com>
> > >>> > > wrote:
> > >>> > >
> > >>> > >> Hi Andrei,
> > >>> > >>
> > >>> > >> I uploaded your key to the file. Please check.
> > >>> > >>
> > >>> > >> Normally you don't need to be in the PMC to have access to the
> svn
> > >>> repo.
> > >>> > >> I don't know what went wrong and you were not able to push it
> > >>> through.
> > >>> > >>
> > >>> > >> Best,
> > >>> > >> Stamatis
> > >>> > >>
> > >>> > >> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda  >
> > >>> wrote:
> > >>> > >>
> > >>> > >>> Hello,
> > >>> > >>>
> > >>> > >>> Can somebody from PMC pls upload my public GPG key to KEYS
> > >>> > >>>  ? I
> > >>> don't
> > >>> > have
> > >>> > >>> permissions for that svn repo.
> > >>> > >>>
> > >>> > >>> I've sent an email to priv...@calcite.apache.org.
> > >>> > >>>
> > >>> > >>> Thanks,
> > >>> > >>> Andrei.
> > >>> > >>>
> > >>> > >>> On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda  >
> > >>> > wrote:
> > >>> > >>>
> > >>> >  Hi All,
> > >>> > 
> > >>> >  I plan to close the vote tomorrow (Aug 12th). If you still
> want to
> > >>> >  validate RC0 please do so before Wednesday.
> > >>> > 
> > >>> >  Regards,
> > >>> >  Andrei.
> > >>> > 
> > >>> >  On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda
> 
> > >>> > >> wrote:
> > >>> > 
> > >>> > > Thanks, Julian, for the hint. I'll update the KEYS file.
> > >>> > >
> > >>> > > On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde <
> > >>> jhyde.apa...@gmail.com
> > >>> > >
> > >>> > > wrote:
> > >>> > >
> > >>> > >> Andrei,
> > >>> > >>
> > >>> > >> Your key’s signature appears in KEYS because you signed
> > >>> Stamatis’s
> > 

Re: [DISCUSS] Open SVN dist access to committers

[Ruben Q L]

+1

Apart from the reasons already mentioned, if we want committers (not just
PMC) to get involved in the release management process, I think this step
would go in the right direction.

Best regards,
Ruben


Le jeu. 13 août 2020 à 23:18, Rui Wang  a écrit :

> +1
>
> if well used/tested svn commands for releasing are documented, committers
> without experience on release or svn can still use those properly.
>
>
> -Rui
>
> On Thu, Aug 13, 2020 at 3:09 PM Stamatis Zampetakis 
> wrote:
>
> > +1
> >
> > I always thought that committers had access to the dist repo and I was
> > completely fine with it.
> >
> > Everybody makes mistakes no matter if it is a committer or PMC so I don't
> > see a reason to have different read/write access to the repo.
> >
> > Best,
> > Stamatis
> >
> > On Fri, Aug 14, 2020 at 12:17 AM sebbaz  wrote:
> >
> > >
> > >
> > > On 2020/08/13 18:47:54, Julian Hyde  wrote:
> > > > +1
> > > >
> > > > Clearly committers should have read and write access to all
> non-private
> > > information in a project. I don’t even think this needs a vote. If this
> > > discussion quickly reaches consensus, as I assume it will, let’s just
> > make
> > > it so.
> > > >
> > > > The hypothetical risk that a committer would (accidentally or
> > > deliberately) cause damage is a non-issue. In source control systems
> such
> > > as SVN or Git, any change can be rolled back.
> > >
> > > Please note that the dist.apache.org release directory is very
> different
> > > in this regard.
> > >
> > > If artifacts are published by moving them to the release directory, it
> is
> > > *not* easily possible to revert publication
> > >
> > > This is because the release directory is used to distribute the files
> to
> > > the world-wide mirror system.
> > > And to the ASF archive system, which would require Infra assistance to
> > > revert.
> > >
> > > Mistakes are not easily recovered.
> > >
> > > This is why the default is for PMC members only.
> > >
> > > > Julian
> > > >
> > > >
> > > > > On Aug 13, 2020, at 8:07 AM, Andrei Sereda 
> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > For the last two releases ([1] and [2]) committers were not able to
> > > > > finalize the release due to SVN restrictions. One of the PMC
> members
> > > had to
> > > > > step in order to distribute the artifacts.
> > > > >
> > > > > By default, only PMCs are allowed to make changes to dist
> > > > >  SVN
> > repository.
> > > > >
> > > > > This can be changed
> > > > > <
> > >
> >
> https://issues.apache.org/jira/browse/INFRA-20681?focusedCommentId=17177075&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17177075
> > > >.
> > > > > According to INFA:
> > > > >
> > > > >> A link on this Jira to an email discussion where it is approved
> will
> > > be
> > > > > fine
> > > > >
> > > > > PMCs please vote on this proposal.
> > > > >
> > > > > Thanks,
> > > > > Andrei.
> > > > >
> > > > > [1]
> > > > >
> > >
> >
> https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E
> > > > > [2]
> > > > >
> > >
> >
> https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Open SVN dist access to committers

[Rui Wang]

+1

if well used/tested svn commands for releasing are documented, committers
without experience on release or svn can still use those properly.


-Rui

On Thu, Aug 13, 2020 at 3:09 PM Stamatis Zampetakis 
wrote:

> +1
>
> I always thought that committers had access to the dist repo and I was
> completely fine with it.
>
> Everybody makes mistakes no matter if it is a committer or PMC so I don't
> see a reason to have different read/write access to the repo.
>
> Best,
> Stamatis
>
> On Fri, Aug 14, 2020 at 12:17 AM sebbaz  wrote:
>
> >
> >
> > On 2020/08/13 18:47:54, Julian Hyde  wrote:
> > > +1
> > >
> > > Clearly committers should have read and write access to all non-private
> > information in a project. I don’t even think this needs a vote. If this
> > discussion quickly reaches consensus, as I assume it will, let’s just
> make
> > it so.
> > >
> > > The hypothetical risk that a committer would (accidentally or
> > deliberately) cause damage is a non-issue. In source control systems such
> > as SVN or Git, any change can be rolled back.
> >
> > Please note that the dist.apache.org release directory is very different
> > in this regard.
> >
> > If artifacts are published by moving them to the release directory, it is
> > *not* easily possible to revert publication
> >
> > This is because the release directory is used to distribute the files to
> > the world-wide mirror system.
> > And to the ASF archive system, which would require Infra assistance to
> > revert.
> >
> > Mistakes are not easily recovered.
> >
> > This is why the default is for PMC members only.
> >
> > > Julian
> > >
> > >
> > > > On Aug 13, 2020, at 8:07 AM, Andrei Sereda  wrote:
> > > >
> > > > Hello,
> > > >
> > > > For the last two releases ([1] and [2]) committers were not able to
> > > > finalize the release due to SVN restrictions. One of the PMC members
> > had to
> > > > step in order to distribute the artifacts.
> > > >
> > > > By default, only PMCs are allowed to make changes to dist
> > > >  SVN
> repository.
> > > >
> > > > This can be changed
> > > > <
> >
> https://issues.apache.org/jira/browse/INFRA-20681?focusedCommentId=17177075&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17177075
> > >.
> > > > According to INFA:
> > > >
> > > >> A link on this Jira to an email discussion where it is approved will
> > be
> > > > fine
> > > >
> > > > PMCs please vote on this proposal.
> > > >
> > > > Thanks,
> > > > Andrei.
> > > >
> > > > [1]
> > > >
> >
> https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E
> > > > [2]
> > > >
> >
> https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E
> > >
> > >
> >
>

Re: [DISCUSS] Open SVN dist access to committers

[Stamatis Zampetakis]

+1

I always thought that committers had access to the dist repo and I was
completely fine with it.

Everybody makes mistakes no matter if it is a committer or PMC so I don't
see a reason to have different read/write access to the repo.

Best,
Stamatis

On Fri, Aug 14, 2020 at 12:17 AM sebbaz  wrote:

>
>
> On 2020/08/13 18:47:54, Julian Hyde  wrote:
> > +1
> >
> > Clearly committers should have read and write access to all non-private
> information in a project. I don’t even think this needs a vote. If this
> discussion quickly reaches consensus, as I assume it will, let’s just make
> it so.
> >
> > The hypothetical risk that a committer would (accidentally or
> deliberately) cause damage is a non-issue. In source control systems such
> as SVN or Git, any change can be rolled back.
>
> Please note that the dist.apache.org release directory is very different
> in this regard.
>
> If artifacts are published by moving them to the release directory, it is
> *not* easily possible to revert publication
>
> This is because the release directory is used to distribute the files to
> the world-wide mirror system.
> And to the ASF archive system, which would require Infra assistance to
> revert.
>
> Mistakes are not easily recovered.
>
> This is why the default is for PMC members only.
>
> > Julian
> >
> >
> > > On Aug 13, 2020, at 8:07 AM, Andrei Sereda  wrote:
> > >
> > > Hello,
> > >
> > > For the last two releases ([1] and [2]) committers were not able to
> > > finalize the release due to SVN restrictions. One of the PMC members
> had to
> > > step in order to distribute the artifacts.
> > >
> > > By default, only PMCs are allowed to make changes to dist
> > >  SVN repository.
> > >
> > > This can be changed
> > > <
> https://issues.apache.org/jira/browse/INFRA-20681?focusedCommentId=17177075&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17177075
> >.
> > > According to INFA:
> > >
> > >> A link on this Jira to an email discussion where it is approved will
> be
> > > fine
> > >
> > > PMCs please vote on this proposal.
> > >
> > > Thanks,
> > > Andrei.
> > >
> > > [1]
> > >
> https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E
> > > [2]
> > >
> https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E
> >
> >
>

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

[Haisheng Yuan]

Hi Andrei,

Let's unblock the release as soon as possible.
I can help publish the artifact.

Can you cat build/stagingRepositories/nexus.txt and send me the content in your 
local repo?

Thanks,
Haisheng

On 2020/08/13 14:47:05, Andrei Sereda  wrote: 
> It can also be configured per project.
> 
> > Do you know if SVN access can be configured per project ?
> > Yes it can, if the PMC agrees to it, the dist area can be opened up to
> all project committers - a few PMCs have done this.
> 
> On Thu, Aug 13, 2020 at 10:43 AM Andrei Sereda  wrote:
> 
> > Inquired with INFRA-20681
> >  seems like only PMCs
> > can commit to dist SVN:
> >
> > > Are committers (which are not PMCs) allowed to commit to SVN dist repo ?
> > > ..., nope, by default its PMC members only
> >
> >
> >
> > On Thu, Aug 13, 2020 at 9:27 AM Andrei Sereda  wrote:
> >
> >> Can someone from PMC pls publish the release ?  Or maybe contact INFRA
> >> about svn permissions for committers vs PMCs ?
> >>
> >> I would like to avoid blocking calcite development for too long.
> >>
> >>
> >> On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei 
> >> wrote:
> >>
> >>> > Once this release is done, we should consider whether we should give
> >>> committers write access to SVN to avoid these issues in the future. I am
> >>> not sure if this is possible or if this is just the way ASF's infra is
> >>> set up, but it's worth a look.
> >>>
> >>> I cannot agree more. Thank you for pointing out, Francis.
> >>> (We can add some notes about it at least~~)
> >>>
> >>>
> >>>
> >>> Best,
> >>> Chunwei
> >>>
> >>>
> >>> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang <
> >>> francischu...@apache.org>
> >>> wrote:
> >>>
> >>> > Can someone please push the release artifacts for Andrei? I believe
> >>> this
> >>> > is the same issue we had with the last release, where the RM is not a
> >>> > PMC member and doesn't have write access to SVN [1].
> >>> >
> >>> > Once this release is done, we should consider whether we should give
> >>> > committers write access to SVN to avoid these issues in the future. I
> >>> am
> >>> > not sure if this is possible or if this is just the way ASF's infra is
> >>> > set up, but it's worth a look.
> >>> >
> >>> > Francis
> >>> >
> >>> > [1]
> >>> >
> >>> >
> >>> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
> >>> >
> >>> > On 13/08/2020 8:51 am, Andrei Sereda wrote:
> >>> > > Thanks, Stamatis. All seems to be working now.
> >>> > >
> >>> > > On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis <
> >>> zabe...@gmail.com>
> >>> > > wrote:
> >>> > >
> >>> > >> Hi Andrei,
> >>> > >>
> >>> > >> I uploaded your key to the file. Please check.
> >>> > >>
> >>> > >> Normally you don't need to be in the PMC to have access to the svn
> >>> repo.
> >>> > >> I don't know what went wrong and you were not able to push it
> >>> through.
> >>> > >>
> >>> > >> Best,
> >>> > >> Stamatis
> >>> > >>
> >>> > >> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda 
> >>> wrote:
> >>> > >>
> >>> > >>> Hello,
> >>> > >>>
> >>> > >>> Can somebody from PMC pls upload my public GPG key to KEYS
> >>> > >>>  ? I
> >>> don't
> >>> > have
> >>> > >>> permissions for that svn repo.
> >>> > >>>
> >>> > >>> I've sent an email to priv...@calcite.apache.org.
> >>> > >>>
> >>> > >>> Thanks,
> >>> > >>> Andrei.
> >>> > >>>
> >>> > >>> On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda 
> >>> > wrote:
> >>> > >>>
> >>> >  Hi All,
> >>> > 
> >>> >  I plan to close the vote tomorrow (Aug 12th). If you still want to
> >>> >  validate RC0 please do so before Wednesday.
> >>> > 
> >>> >  Regards,
> >>> >  Andrei.
> >>> > 
> >>> >  On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda 
> >>> > >> wrote:
> >>> > 
> >>> > > Thanks, Julian, for the hint. I'll update the KEYS file.
> >>> > >
> >>> > > On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde <
> >>> jhyde.apa...@gmail.com
> >>> > >
> >>> > > wrote:
> >>> > >
> >>> > >> Andrei,
> >>> > >>
> >>> > >> Your key’s signature appears in KEYS because you signed
> >>> Stamatis’s
> >>> > >> key.
> >>> > >> But your key isn’t actually defined in the file. After I
> >>> imported
> >>> > the
> >>> > >>> file,
> >>> > >> your key was still ‘unknown’ according to gpg.
> >>> > >>
> >>> > >> Julian
> >>> > >>
> >>> > >>> On Aug 11, 2020, at 8:04 AM, Andrei Sereda 
> >>> > >> wrote:
> >>> > >>>
> >>> > >>> 
> >>> > 
> >>> >  * Andrei, I don’t think your key is in KEYS. Be sure to add it
> >>> > >>> before
> >>> > >> the
> >>> > >>> release announcement.
> >>> > >>>
> >>> > >>> I see my signing key in KEYS
> >>> > >>> $ curl -s
> >>> https://dist.apache.org/repos/dist/release/calcite/KEYS
> >>> > >> |
> >>> > >> grep
> >>> > >>> sereda
> >>> > >>> sig 

Re: [DISCUSS] Open SVN dist access to committers

[sebbaz]

On 2020/08/13 18:47:54, Julian Hyde  wrote: 
> +1
> 
> Clearly committers should have read and write access to all non-private 
> information in a project. I don’t even think this needs a vote. If this 
> discussion quickly reaches consensus, as I assume it will, let’s just make it 
> so.
> 
> The hypothetical risk that a committer would (accidentally or deliberately) 
> cause damage is a non-issue. In source control systems such as SVN or Git, 
> any change can be rolled back.

Please note that the dist.apache.org release directory is very different in 
this regard.

If artifacts are published by moving them to the release directory, it is *not* 
easily possible to revert publication

This is because the release directory is used to distribute the files to the 
world-wide mirror system.
And to the ASF archive system, which would require Infra assistance to revert.

Mistakes are not easily recovered.

This is why the default is for PMC members only.

> Julian
> 
> 
> > On Aug 13, 2020, at 8:07 AM, Andrei Sereda  wrote:
> > 
> > Hello,
> > 
> > For the last two releases ([1] and [2]) committers were not able to
> > finalize the release due to SVN restrictions. One of the PMC members had to
> > step in order to distribute the artifacts.
> > 
> > By default, only PMCs are allowed to make changes to dist
> >  SVN repository.
> > 
> > This can be changed
> > .
> > According to INFA:
> > 
> >> A link on this Jira to an email discussion where it is approved will be
> > fine
> > 
> > PMCs please vote on this proposal.
> > 
> > Thanks,
> > Andrei.
> > 
> > [1]
> > https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E
> > [2]
> > https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E
> 
> 

Re: [DISCUSS] Sarg (search argument) to generalize and replace IN in RexCall

[Julian Hyde]

I have logged https://issues.apache.org/jira/browse/CALCITE-4173 
 and am close to a 
prototype.

See comments inline, below.

> On Aug 11, 2020, at 3:39 PM, Haisheng Yuan  wrote:
> 
>> I am proposing to use sargs only where we would today use RexCall(IN). The 
>> data structures have about the same size. Sargs are sorted. I cannot see any 
>> cases that would become more expensive.
> 
> IIRC, RexCall(IN) is not supported yet.

It’s not officially supported. But it is there - added in 
https://issues.apache.org/jira/browse/CALCITE-2444 
 for just Rel-to-Sql part 
of the process, and people seem to be using it elsewhere, e.g. 
https://issues.apache.org/jira/browse/CALCITE-1413 
 handles IN in CASE.

I have not used RexCall.IN personally. I think there’s too much cost (in making 
all places aware of the IN operator) and not enough benefit (because it cannot 
handle ranges or <>).

One part of the cost is null-semantics. If the values are not literals, one of 
them might evaluate to NULL. So we have to be very conservative, especially 
when optimizing “NOT IN (list)”. There are no tests for that simplification, so 
we’re probably doing it wrong.

So, I propose to remove IN.

> With sargs, you have to sort it, no matter explicitly or implicitly, in case 
> 20k values, it will take some time.

I am not too concerned about the cost of sorting. If you have parsed and 
validated an IN list with 20k items, the query has already burned a few CPU 
cycles.

The Sarg data structure is immutable and one instance should suffice for the 
whole planning process, so the cost of sorting on creation is more than repaid 
by the faster access later on.

> I am not saying the data structure itself is expensive, but how it is used, 
> it all depends on how downstream projects derive stats from it. I have seen 
> Greenplum optimizer experienced performance issue for large IN list when 
> deriving all the stats info from the thousands of disjoint range intervals. 
> Some downstream project may not even use histogram. Some may just use the 
> number of IN constants to derive the number of distinct values, I would 
> imagine people have to construct the Sarg back to constant list, this is an 
> extra burden. 

If there are performance issues, we can add extra operations to the Sarg data 
structure without changing its size/cost. For example, record whether all the 
ranges are points. And if so, efficiently iterate over all the values.

> Suppose we have col in (1,2,4,6,8,10, 12,13, 15,17,19, 21,22, 24, 24+2.) 
> 10k values, now the range sets will be {[1,2], [4,4], [10,10], [12,13], 
> [15,15][21,22], [24,24]}, in the execution engine, what if I want to 
> do the look up for this expression? Find out the points, extract ranges and 
> disjoint them, or infer points from integer ranges?

You should transcribe the Sarg into a data structure that makes sense for your 
execution engine. Say a bloom filter, a compressed bitmap, or a perfect hash.

> IMHO, the interval constraint is more like a kind of logical property and can 
> be strategy for simplification, people can derive the interval constraints 
> from the IN list, do simplification on it (but I doubt the value in practice, 
> which usually brings more trouble than benefits), but we don't have to 
> represent it with sarg in RexNode world.

I agree that it should be a logical property. It should be part of 
RelOptPredicateList. But to apply those predicates efficiently, we need one 
predicate that searches in a range rather than 20k predicates.

> I am not asking sargs to support geospatial operations. And geospatial 
> intersect is just an example of potential customized operation, which are not 
> limited to geospatials. It can be some other binary operations. We can't 
> require all the customized operation to have something like ST_Collect. 

Sure, there are other techniques. One of which is generating rasters (e.g. if 
you are doing a spatial join of states to national parks, pre-generate for each 
national park a bitmap of the all 100x100km squares, and put a 1 in the square 
if it overlaps the park). Rasters are kind of similar to sargs.

I have been working on space-filling curves as indexes for point-to-shape 
joins, as part of https://issues.apache.org/jira/browse/CALCITE-1861 
. In 
https://github.com/julianhyde/calcite/blob/829c33a524adb727482df27d605d193a0c7a280c/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L7966
 

 see how we transform a call to ST_DWithin to the predicate 

LogicalFilter(condition=[AND(OR(AND(>=($4, 36496), <=($4, 36520)), AND(>=($4, 
36456), <=($4, 3

Re: [ANNOUNCE] Ruben Quesada Lopez joins Calcite PMC

[Julian Hyde]

Thanks for your hard work on the project and in the community, Ruben. Well 
deserved.

Julian


> On Aug 13, 2020, at 6:19 AM, Thomas Rebele  wrote:
> 
> Congrats, Ruben!
> 
> Cordialement / Best Regards,
> *Thomas Rebele* | R&D Developer | 18 rue du 4 septembre, 75002 Paris, France
> | www.tibco.com
> 
> 
> On Thu, Aug 13, 2020 at 12:54 AM Francis Chuang 
> wrote:
> 
>> Congratulations, Ruben!
>> 
>> Francis
>> 
>> On 13/08/2020 3:43 am, Andrei Sereda wrote:
>>> Congratulations, Ruben!
>>> 
>>> On Wed, Aug 12, 2020 at 1:21 PM Rui Wang  wrote:
>>> 
 Congrats, Ruben! Well deserved!
 
 
 
 -Rui
 
 On Wed, Aug 12, 2020 at 9:24 AM Enrico Olivelli 
 wrote:
 
> Congrats Ruben!
> 
> Enrico
> 
> Il Mer 12 Ago 2020, 18:05 Michael Mior  ha scritto:
> 
>> Congrats Reuben!
>> 
>> --
>> Michael Mior
>> mm...@apache.org
>> 
>> Le mer. 12 août 2020 à 09:32, Ruben Q L  a écrit :
>>> 
>>> Thanks everyone!
>>> It is an honor to join the Calcite PMC.
>>> 
>>> Best regards,
>>> Ruben
>>> 
>>> 
>>> Le mer. 12 août 2020 à 03:03, Forward Xu  a
>> écrit :
>>> 
 Congrats, Ruben!
 
 
 Best
 
 Forward
 
 XING JIN  于2020年8月12日周三 上午8:58写道：
 
> Congrats, Ruben!
> 
> 953396112 <953396...@qq.com> 于2020年8月12日周三 上午7:47写道：
> 
>> Congratulations, Ruben!
>> 
>> 
>> xzh
>> -- 原始邮件 --
>> 发件人:
>>   "dev"
>> 
  <
>> zabe...@gmail.com>;
>> 发送时间: 2020年8月12日(星期三) 凌晨5:53
>> 收件人: "dev"> 
>> 主题: [ANNOUNCE] Ruben Quesada Lopez joins Calcite PMC
>> 
>> 
>> 
>> I'm pleased to announce that Ruben has accepted an invitation
 to
>> join the Calcite PMC. Ruben has been a consistent and helpful
>> figure in the Calcite community for which we are very grateful.
> We
>> look forward to the continued contributions and support.
>> 
>> Please join me in congratulating Ruben!
>> 
>> - Stamatis (on behalf of the Calcite PMC)
> 
 
>> 
> 
 
>>> 
>> 

Re: [DISCUSS] Open SVN dist access to committers

[Julian Hyde]

+1

Clearly committers should have read and write access to all non-private 
information in a project. I don’t even think this needs a vote. If this 
discussion quickly reaches consensus, as I assume it will, let’s just make it 
so.

The hypothetical risk that a committer would (accidentally or deliberately) 
cause damage is a non-issue. In source control systems such as SVN or Git, any 
change can be rolled back.

Julian


> On Aug 13, 2020, at 8:07 AM, Andrei Sereda  wrote:
> 
> Hello,
> 
> For the last two releases ([1] and [2]) committers were not able to
> finalize the release due to SVN restrictions. One of the PMC members had to
> step in order to distribute the artifacts.
> 
> By default, only PMCs are allowed to make changes to dist
>  SVN repository.
> 
> This can be changed
> .
> According to INFA:
> 
>> A link on this Jira to an email discussion where it is approved will be
> fine
> 
> PMCs please vote on this proposal.
> 
> Thanks,
> Andrei.
> 
> [1]
> https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E
> [2]
> https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E

Re: [DISCUSSION] Rename master branch to main

[Laurent Goujon]

Hi,

+1 for me too.

On Wed, Aug 12, 2020 at 11:07 AM Josh Elser  wrote:

> +1 change it.
>
> On 7/28/20 1:43 PM, Julian Hyde wrote:
> > I am in favor of renaming ‘master’ to ‘main’. To most people it doesn’t
> make any difference. To some, such as potential members currently outside
> the community, it makes the project more welcoming.
> >
> > Very little effort or disruption is required. We’ve identified a
> potential source of friction, so let’s fix it and move on.
> >
> > Julian
> >
> >> On Jul 28, 2020, at 10:31 AM, Michael Mior  wrote:
> >>
> >> Hi all,
> >>
> >> You can find some background on this discussion at the link below [0].
> >> This is a topic that has come up regularly among D&I folks at the ASF.
> >> The short summary is that the term "master" when referring to a git
> >> branch is a reference to terminology related to slavery. I'm
> >> suggesting main because this seems to be what the developer community
> >> as a whole is gravitating towards. See for example, GitHub's public
> >> roadmap [1] where there are plans to make this change.
> >>
> >> I'm hoping that this discussion can be focused not on whether anyone
> >> has been impacted by such terminology, but how we can move forward. I
> >> personally believe that if a single person feels more welcome to
> >> contribute because of the change, it's a win. I also don't think
> >> making this change needs to be painful. (There are less than 20
> >> relevant references to "master" in the Calcite code.) Apache Mahout
> >> and I believe others have already made this change.
> >>
> >> I think this is a relatively low impact change that can potentially
> >> make us even more welcoming to new contributors, which is a benefit to
> >> us all :)
> >>
> >> [0]
> http://www.kapwing.com/blog/how-to-rename-your-master-branch-to-main-in-git/
> >> [1] https://github.com/github/roadmap/issues/63
> >>
> >> --
> >> Michael Mior
> >> mm...@apache.org
> >
>

[DISCUSS] Open SVN dist access to committers

[Andrei Sereda]

Hello,

For the last two releases ([1] and [2]) committers were not able to
finalize the release due to SVN restrictions. One of the PMC members had to
step in order to distribute the artifacts.

By default, only PMCs are allowed to make changes to dist
 SVN repository.

This can be changed
.
According to INFA:

> A link on this Jira to an email discussion where it is approved will be
fine

PMCs please vote on this proposal.

Thanks,
Andrei.

[1]
https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E
[2]
https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

[Andrei Sereda]

It can also be configured per project.

> Do you know if SVN access can be configured per project ?
> Yes it can, if the PMC agrees to it, the dist area can be opened up to
all project committers - a few PMCs have done this.

On Thu, Aug 13, 2020 at 10:43 AM Andrei Sereda  wrote:

> Inquired with INFRA-20681
>  seems like only PMCs
> can commit to dist SVN:
>
> > Are committers (which are not PMCs) allowed to commit to SVN dist repo ?
> > ..., nope, by default its PMC members only
>
>
>
> On Thu, Aug 13, 2020 at 9:27 AM Andrei Sereda  wrote:
>
>> Can someone from PMC pls publish the release ?  Or maybe contact INFRA
>> about svn permissions for committers vs PMCs ?
>>
>> I would like to avoid blocking calcite development for too long.
>>
>>
>> On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei 
>> wrote:
>>
>>> > Once this release is done, we should consider whether we should give
>>> committers write access to SVN to avoid these issues in the future. I am
>>> not sure if this is possible or if this is just the way ASF's infra is
>>> set up, but it's worth a look.
>>>
>>> I cannot agree more. Thank you for pointing out, Francis.
>>> (We can add some notes about it at least~~)
>>>
>>>
>>>
>>> Best,
>>> Chunwei
>>>
>>>
>>> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang <
>>> francischu...@apache.org>
>>> wrote:
>>>
>>> > Can someone please push the release artifacts for Andrei? I believe
>>> this
>>> > is the same issue we had with the last release, where the RM is not a
>>> > PMC member and doesn't have write access to SVN [1].
>>> >
>>> > Once this release is done, we should consider whether we should give
>>> > committers write access to SVN to avoid these issues in the future. I
>>> am
>>> > not sure if this is possible or if this is just the way ASF's infra is
>>> > set up, but it's worth a look.
>>> >
>>> > Francis
>>> >
>>> > [1]
>>> >
>>> >
>>> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
>>> >
>>> > On 13/08/2020 8:51 am, Andrei Sereda wrote:
>>> > > Thanks, Stamatis. All seems to be working now.
>>> > >
>>> > > On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis <
>>> zabe...@gmail.com>
>>> > > wrote:
>>> > >
>>> > >> Hi Andrei,
>>> > >>
>>> > >> I uploaded your key to the file. Please check.
>>> > >>
>>> > >> Normally you don't need to be in the PMC to have access to the svn
>>> repo.
>>> > >> I don't know what went wrong and you were not able to push it
>>> through.
>>> > >>
>>> > >> Best,
>>> > >> Stamatis
>>> > >>
>>> > >> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda 
>>> wrote:
>>> > >>
>>> > >>> Hello,
>>> > >>>
>>> > >>> Can somebody from PMC pls upload my public GPG key to KEYS
>>> > >>>  ? I
>>> don't
>>> > have
>>> > >>> permissions for that svn repo.
>>> > >>>
>>> > >>> I've sent an email to priv...@calcite.apache.org.
>>> > >>>
>>> > >>> Thanks,
>>> > >>> Andrei.
>>> > >>>
>>> > >>> On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda 
>>> > wrote:
>>> > >>>
>>> >  Hi All,
>>> > 
>>> >  I plan to close the vote tomorrow (Aug 12th). If you still want to
>>> >  validate RC0 please do so before Wednesday.
>>> > 
>>> >  Regards,
>>> >  Andrei.
>>> > 
>>> >  On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda 
>>> > >> wrote:
>>> > 
>>> > > Thanks, Julian, for the hint. I'll update the KEYS file.
>>> > >
>>> > > On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde <
>>> jhyde.apa...@gmail.com
>>> > >
>>> > > wrote:
>>> > >
>>> > >> Andrei,
>>> > >>
>>> > >> Your key’s signature appears in KEYS because you signed
>>> Stamatis’s
>>> > >> key.
>>> > >> But your key isn’t actually defined in the file. After I
>>> imported
>>> > the
>>> > >>> file,
>>> > >> your key was still ‘unknown’ according to gpg.
>>> > >>
>>> > >> Julian
>>> > >>
>>> > >>> On Aug 11, 2020, at 8:04 AM, Andrei Sereda 
>>> > >> wrote:
>>> > >>>
>>> > >>> 
>>> > 
>>> >  * Andrei, I don’t think your key is in KEYS. Be sure to add it
>>> > >>> before
>>> > >> the
>>> > >>> release announcement.
>>> > >>>
>>> > >>> I see my signing key in KEYS
>>> > >>> $ curl -s
>>> https://dist.apache.org/repos/dist/release/calcite/KEYS
>>> > >> |
>>> > >> grep
>>> > >>> sereda
>>> > >>> sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE
>>> > >> SIGNING
>>> > >> KEY) <
>>> > >>> ser...@apache.org>
>>> > >>> sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE
>>> > >> SIGNING
>>> > >> KEY) <
>>> > >>> ser...@apache.org>
>>> > >>>
>>> >  * There are several files in the source distro that are not in
>>> > >> git:
>>> > >>> an
>>> > >>> empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
>>> > >>> Yes you're right. I presume you're still OK with RC0 (judging
>>> by

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

[Andrei Sereda]

Inquired with INFRA-20681
 seems like only PMCs
can commit to dist SVN:

> Are committers (which are not PMCs) allowed to commit to SVN dist repo ?
> ..., nope, by default its PMC members only



On Thu, Aug 13, 2020 at 9:27 AM Andrei Sereda  wrote:

> Can someone from PMC pls publish the release ?  Or maybe contact INFRA
> about svn permissions for committers vs PMCs ?
>
> I would like to avoid blocking calcite development for too long.
>
>
> On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei 
> wrote:
>
>> > Once this release is done, we should consider whether we should give
>> committers write access to SVN to avoid these issues in the future. I am
>> not sure if this is possible or if this is just the way ASF's infra is
>> set up, but it's worth a look.
>>
>> I cannot agree more. Thank you for pointing out, Francis.
>> (We can add some notes about it at least~~)
>>
>>
>>
>> Best,
>> Chunwei
>>
>>
>> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang > >
>> wrote:
>>
>> > Can someone please push the release artifacts for Andrei? I believe this
>> > is the same issue we had with the last release, where the RM is not a
>> > PMC member and doesn't have write access to SVN [1].
>> >
>> > Once this release is done, we should consider whether we should give
>> > committers write access to SVN to avoid these issues in the future. I am
>> > not sure if this is possible or if this is just the way ASF's infra is
>> > set up, but it's worth a look.
>> >
>> > Francis
>> >
>> > [1]
>> >
>> >
>> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
>> >
>> > On 13/08/2020 8:51 am, Andrei Sereda wrote:
>> > > Thanks, Stamatis. All seems to be working now.
>> > >
>> > > On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis <
>> zabe...@gmail.com>
>> > > wrote:
>> > >
>> > >> Hi Andrei,
>> > >>
>> > >> I uploaded your key to the file. Please check.
>> > >>
>> > >> Normally you don't need to be in the PMC to have access to the svn
>> repo.
>> > >> I don't know what went wrong and you were not able to push it
>> through.
>> > >>
>> > >> Best,
>> > >> Stamatis
>> > >>
>> > >> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda 
>> wrote:
>> > >>
>> > >>> Hello,
>> > >>>
>> > >>> Can somebody from PMC pls upload my public GPG key to KEYS
>> > >>>  ? I don't
>> > have
>> > >>> permissions for that svn repo.
>> > >>>
>> > >>> I've sent an email to priv...@calcite.apache.org.
>> > >>>
>> > >>> Thanks,
>> > >>> Andrei.
>> > >>>
>> > >>> On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda 
>> > wrote:
>> > >>>
>> >  Hi All,
>> > 
>> >  I plan to close the vote tomorrow (Aug 12th). If you still want to
>> >  validate RC0 please do so before Wednesday.
>> > 
>> >  Regards,
>> >  Andrei.
>> > 
>> >  On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda 
>> > >> wrote:
>> > 
>> > > Thanks, Julian, for the hint. I'll update the KEYS file.
>> > >
>> > > On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde <
>> jhyde.apa...@gmail.com
>> > >
>> > > wrote:
>> > >
>> > >> Andrei,
>> > >>
>> > >> Your key’s signature appears in KEYS because you signed
>> Stamatis’s
>> > >> key.
>> > >> But your key isn’t actually defined in the file. After I imported
>> > the
>> > >>> file,
>> > >> your key was still ‘unknown’ according to gpg.
>> > >>
>> > >> Julian
>> > >>
>> > >>> On Aug 11, 2020, at 8:04 AM, Andrei Sereda 
>> > >> wrote:
>> > >>>
>> > >>> 
>> > 
>> >  * Andrei, I don’t think your key is in KEYS. Be sure to add it
>> > >>> before
>> > >> the
>> > >>> release announcement.
>> > >>>
>> > >>> I see my signing key in KEYS
>> > >>> $ curl -s
>> https://dist.apache.org/repos/dist/release/calcite/KEYS
>> > >> |
>> > >> grep
>> > >>> sereda
>> > >>> sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE
>> > >> SIGNING
>> > >> KEY) <
>> > >>> ser...@apache.org>
>> > >>> sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE
>> > >> SIGNING
>> > >> KEY) <
>> > >>> ser...@apache.org>
>> > >>>
>> >  * There are several files in the source distro that are not in
>> > >> git:
>> > >>> an
>> > >>> empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
>> > >>> Yes you're right. I presume you're still OK with RC0 (judging by
>> > >> your
>> > >> +1) ?
>> > >>>
>> > >>>
>> >  On Tue, Aug 11, 2020 at 5:53 AM Julian Hyde <
>> > >> jhyde.apa...@gmail.com
>> > 
>> > >> wrote:
>> > 
>> >  +1 (binding)
>> > 
>> >  Checked keys, hashes, LICENSE, NOTICE, README; compiled and ran
>> > >>> tests
>> > >> on
>> >  Ubuntu/JDK 14; ran RAT.
>> > 
>> >  * Andrei, I don’t think your key is in KEYS. Be sure to add it
>> > >>> before

Re: [VOTE] Release apache-calcite-1.25.0 (release candidate 0)

[Andrei Sereda]

Can someone from PMC pls publish the release ?  Or maybe contact INFRA
about svn permissions for committers vs PMCs ?

I would like to avoid blocking calcite development for too long.


On Wed, Aug 12, 2020 at 11:33 PM Chunwei Lei  wrote:

> > Once this release is done, we should consider whether we should give
> committers write access to SVN to avoid these issues in the future. I am
> not sure if this is possible or if this is just the way ASF's infra is
> set up, but it's worth a look.
>
> I cannot agree more. Thank you for pointing out, Francis.
> (We can add some notes about it at least~~)
>
>
>
> Best,
> Chunwei
>
>
> On Thu, Aug 13, 2020 at 10:22 AM Francis Chuang 
> wrote:
>
> > Can someone please push the release artifacts for Andrei? I believe this
> > is the same issue we had with the last release, where the RM is not a
> > PMC member and doesn't have write access to SVN [1].
> >
> > Once this release is done, we should consider whether we should give
> > committers write access to SVN to avoid these issues in the future. I am
> > not sure if this is possible or if this is just the way ASF's infra is
> > set up, but it's worth a look.
> >
> > Francis
> >
> > [1]
> >
> >
> https://lists.apache.org/thread.html/rdb11cf78eaeecfefd68ce224cd2e6fd1e9f2ad964169d80f5d9cb82a%40%3Cdev.calcite.apache.org%3E
> >
> > On 13/08/2020 8:51 am, Andrei Sereda wrote:
> > > Thanks, Stamatis. All seems to be working now.
> > >
> > > On Wed, Aug 12, 2020 at 6:36 PM Stamatis Zampetakis  >
> > > wrote:
> > >
> > >> Hi Andrei,
> > >>
> > >> I uploaded your key to the file. Please check.
> > >>
> > >> Normally you don't need to be in the PMC to have access to the svn
> repo.
> > >> I don't know what went wrong and you were not able to push it through.
> > >>
> > >> Best,
> > >> Stamatis
> > >>
> > >> On Thu, Aug 13, 2020 at 1:24 AM Andrei Sereda 
> wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> Can somebody from PMC pls upload my public GPG key to KEYS
> > >>>  ? I don't
> > have
> > >>> permissions for that svn repo.
> > >>>
> > >>> I've sent an email to priv...@calcite.apache.org.
> > >>>
> > >>> Thanks,
> > >>> Andrei.
> > >>>
> > >>> On Tue, Aug 11, 2020 at 1:17 PM Andrei Sereda 
> > wrote:
> > >>>
> >  Hi All,
> > 
> >  I plan to close the vote tomorrow (Aug 12th). If you still want to
> >  validate RC0 please do so before Wednesday.
> > 
> >  Regards,
> >  Andrei.
> > 
> >  On Tue, Aug 11, 2020 at 1:13 PM Andrei Sereda 
> > >> wrote:
> > 
> > > Thanks, Julian, for the hint. I'll update the KEYS file.
> > >
> > > On Tue, Aug 11, 2020 at 11:59 AM Julian Hyde <
> jhyde.apa...@gmail.com
> > >
> > > wrote:
> > >
> > >> Andrei,
> > >>
> > >> Your key’s signature appears in KEYS because you signed Stamatis’s
> > >> key.
> > >> But your key isn’t actually defined in the file. After I imported
> > the
> > >>> file,
> > >> your key was still ‘unknown’ according to gpg.
> > >>
> > >> Julian
> > >>
> > >>> On Aug 11, 2020, at 8:04 AM, Andrei Sereda 
> > >> wrote:
> > >>>
> > >>> 
> > 
> >  * Andrei, I don’t think your key is in KEYS. Be sure to add it
> > >>> before
> > >> the
> > >>> release announcement.
> > >>>
> > >>> I see my signing key in KEYS
> > >>> $ curl -s
> https://dist.apache.org/repos/dist/release/calcite/KEYS
> > >> |
> > >> grep
> > >>> sereda
> > >>> sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE
> > >> SIGNING
> > >> KEY) <
> > >>> ser...@apache.org>
> > >>> sig  C41CFDDFED34C028 2019-08-19  Andrei Sereda (CODE
> > >> SIGNING
> > >> KEY) <
> > >>> ser...@apache.org>
> > >>>
> >  * There are several files in the source distro that are not in
> > >> git:
> > >>> an
> > >>> empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
> > >>> Yes you're right. I presume you're still OK with RC0 (judging by
> > >> your
> > >> +1) ?
> > >>>
> > >>>
> >  On Tue, Aug 11, 2020 at 5:53 AM Julian Hyde <
> > >> jhyde.apa...@gmail.com
> > 
> > >> wrote:
> > 
> >  +1 (binding)
> > 
> >  Checked keys, hashes, LICENSE, NOTICE, README; compiled and ran
> > >>> tests
> > >> on
> >  Ubuntu/JDK 14; ran RAT.
> > 
> >  * Andrei, I don’t think your key is in KEYS. Be sure to add it
> > >>> before
> > >> the
> >  release announcement.
> > 
> >  * There are several files in the source distro that are not in
> > >> git:
> > >>> an
> >  empty ‘arrow’ directory, and a non-empty ‘licenses’ directory.
> > 
> >  Julian
> > 
> > 
> > > On Aug 11, 2020, at 2:33 AM, Stamatis Zampetakis <
> > >>> zabe...@gmail.com>
> >  wrote:
> > >
> > > If I remember well the site preview is not implemented

Re: [ANNOUNCE] Ruben Quesada Lopez joins Calcite PMC

[Thomas Rebele]

Congrats, Ruben!

Cordialement / Best Regards,
*Thomas Rebele* | R&D Developer | 18 rue du 4 septembre, 75002 Paris, France
| www.tibco.com


On Thu, Aug 13, 2020 at 12:54 AM Francis Chuang 
wrote:

> Congratulations, Ruben!
>
> Francis
>
> On 13/08/2020 3:43 am, Andrei Sereda wrote:
> > Congratulations, Ruben!
> >
> > On Wed, Aug 12, 2020 at 1:21 PM Rui Wang  wrote:
> >
> >> Congrats, Ruben! Well deserved!
> >>
> >>
> >>
> >> -Rui
> >>
> >> On Wed, Aug 12, 2020 at 9:24 AM Enrico Olivelli 
> >> wrote:
> >>
> >>> Congrats Ruben!
> >>>
> >>> Enrico
> >>>
> >>> Il Mer 12 Ago 2020, 18:05 Michael Mior  ha scritto:
> >>>
>  Congrats Reuben!
> 
>  --
>  Michael Mior
>  mm...@apache.org
> 
>  Le mer. 12 août 2020 à 09:32, Ruben Q L  a écrit :
> >
> > Thanks everyone!
> > It is an honor to join the Calcite PMC.
> >
> > Best regards,
> > Ruben
> >
> >
> > Le mer. 12 août 2020 à 03:03, Forward Xu  a
>  écrit :
> >
> >> Congrats, Ruben!
> >>
> >>
> >> Best
> >>
> >> Forward
> >>
> >> XING JIN  于2020年8月12日周三 上午8:58写道：
> >>
> >>> Congrats, Ruben!
> >>>
> >>> 953396112 <953396...@qq.com> 于2020年8月12日周三 上午7:47写道：
> >>>
>  Congratulations, Ruben!
> 
> 
>  xzh
>  -- 原始邮件 --
>  发件人:
> "dev"
> 
> >>   <
>  zabe...@gmail.com>;
>  发送时间: 2020年8月12日(星期三) 凌晨5:53
>  收件人: "dev" 
>  主题: [ANNOUNCE] Ruben Quesada Lopez joins Calcite PMC
> 
> 
> 
>  I'm pleased to announce that Ruben has accepted an invitation
> >> to
>  join the Calcite PMC. Ruben has been a consistent and helpful
>  figure in the Calcite community for which we are very grateful.
> >>> We
>  look forward to the continued contributions and support.
> 
>  Please join me in congratulating Ruben!
> 
>  - Stamatis (on behalf of the Calcite PMC)
> >>>
> >>
> 
> >>>
> >>
> >
>

[jira] [Created] (CALCITE-4174) avatica-go should handle complex/long URLs

[Josiah Goodson (Jira)]

Josiah Goodson created CALCITE-4174:
---

 Summary: avatica-go should handle complex/long URLs
 Key: CALCITE-4174
 URL: https://issues.apache.org/jira/browse/CALCITE-4174
 Project: Calcite
  Issue Type: Improvement
  Components: avatica-go
Reporter: Josiah Goodson
Assignee: Francis Chuang


The current avatica-go driver assumes the full URL path is the schema name. 
This is incorrect for some deployments - for example, using a proxy.

Current behavior:

dsn = "http://host.com/service/proxy/schema";

conf.schema = "service/proxy/schema"

Expected behavior:

dsn = "http://host.com/service/proxy/schema";

conf.schema = "schema"




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CALCITE-4173) Add internal SEARCH operator and Sarg literal, replacing use of IN in RexCall

[Julian Hyde (Jira)]

Julian Hyde created CALCITE-4173:


 Summary: Add internal SEARCH operator and Sarg literal, replacing 
use of IN in RexCall
 Key: CALCITE-4173
 URL: https://issues.apache.org/jira/browse/CALCITE-4173
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde


Add internal SEARCH operator and Sarg literal, replacing use of IN in RexCall.

Recently we started to allow IN in RexCalls to represent lists of constant 
values; previously it had only been allowed in SqlCall. The use is confusing, 
because a RexSubQuery is a sub-class of RexCall that may also use IN as its 
operator.

More important, we would like to be able to represent more general search 
arguments in a single RexCall. Examples: 
* {{x BETWEEN 3 AND 10}}
* {{x > 3 AND x <= 10}}
* {{x NOT BETWEEN 3 AND 10}}
* {{x IS NULL OR x BETWEEN 3 AND 100 AND x != 50 OR x IN (200, 300, 400)}}
* {{x > 5 AND x < 10 AND x IN (3, 8, 10, 20)}}

All of these can be converted to sets of ranges, where each range has a lower 
or upper bound (or both), bounds can be open or closed, plus a flag to say 
whether NULL is an allowed value. Guava's RangeSet is an efficient 
implementation of range sets.

This change would create a new class {{Sarg}} to represent a range set as a 
literal. The new internal SEARCH operator tests whether an operand belongs to 
the range set.

A RexCall to SEARCH is converted back to SQL, typically an IN or OR.

This change would obsolete the use of IN in {{RexCall}} to represent a fixed 
list of values. (This is a breaking change, but when we first allowed IN in 
{{RexCall}}, in CALCITE-2444, it was only intended to be for 
{{RelToSqlConverter}}. Most people still believe that [IN is not 
allowed|https://lists.apache.org/thread.html/e1c5d56ecca7c1bc3608344ceac9b209bb8100fbca1c1928feb9cce7%40%3Cdev.calcite.apache.org%3E].)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)