[GitHub] hsyuan opened a new pull request #1048: [CALCITE-2722] Rewrite createLeftCall in iterative way instead of recursive way

[GitBox]

hsyuan opened a new pull request #1048: [CALCITE-2722] Rewrite createLeftCall 
in iterative way instead of recursive way
URL: https://github.com/apache/calcite/pull/1048
 
 
   This is intended to avoid potential stack overflow caused by recursive 
function
   call. Codes changes are covered by test case JdbcAdapterTest.testInPlan.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: CalciteRemoteDriverTest vs avatica.MetaImpl vs avatica.server.Main thread safety

[Julian Hyde]

Simplest thing would be a singleton guarded by some kind of lock. But I haven’t 
looked at the code.

> On Feb 15, 2019, at 12:59 PM, Vladimir Sitnikov  
> wrote:
> 
> Julian> allocate a new object per request
> 
> Josh> The Meta implementation inside of the Avatica server is a singleton,
> 
> Julian, I don't think singletones can be allocated per request.
> I don't think final fields of singletones can be changed on a per-request
> basis.
> 
> What's your suggestion then?
> 
> I've created https://issues.apache.org/jira/browse/CALCITE-2853
> It looks like the issue was there for ages, so it does not look like a
> release blocker, however the bug does break CI, and I'm tired of getting
> "build's broken" mails from Apache Jenknis, especially after I commit an
> innocent fix.
> 
> Vladimir

Re: [DISCUSS] Move site repositories from svn to gitbox

[Julian Hyde]

Agreed, the history of the web site is not very important. 

Julian

> On Feb 15, 2019, at 5:58 AM, Michael Mior  wrote:
> 
> I think we may want to keep the old SVN repository around if this is
> the case, but I personally don't have a problem with losing history in
> the new git repo. On a related note, it would be good to find a
> process for the new repo that can work with a shallow clone so we
> don't have to have the entire history of the site to push a change.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> Le ven. 15 févr. 2019 à 05:29, Francis Chuang
>  a écrit :
>> 
>> Hey everyone,
>> 
>> I have now created the calcite-site repo in Gitbox. It is now available
>> via Github and the Gitbox endpoint, but currently empty.
>> 
>> I am currently trying to migrate the svn repo, but it is taking a very
>> long time and eventually timed out for me. A member of the ASF infra
>> team has also confirmed that it can take hours or days to complete [1].
>> 
>> I feel that it would probably be easier if we just copy the existing
>> files from the svn repo and make that the first commit in the git repo.
>> This is what Kafka did for their migration [2].
>> 
>> How important are the commits for site pushes? In my opinion it's
>> probably acceptable if we lose them and start anew with the git repo as
>> they do not document changes to our code base.
>> 
>> Happy to hear your thoughts!
>> 
>> Francis
>> 
>> [1] https://issues.apache.org/jira/browse/INFRA-17846
>> [2]
>> https://github.com/apache/kafka-site/commit/ba6c994ca09629b047ab9175f882877ba03b92da
>> 
>>> On 11/02/2019 9:00 pm, Francis Chuang wrote:
>>> Hey all,
>>> 
>>> ASF project sites have the ability to use git instead of subversion as
>>> their repository for web site content [1]. It has been available since
>>> 2015 and appears to be quite stable. Quite a few other projects have
>>> also moved their websites to git and subsequently, Gitbox (for using
>>> Github as their source of truth. As an example, see the Arrow project [2].
>>> 
>>> I myself would love to see this as I find gits interface and ux to be
>>> much easier to use compared to svn. It also reduces the need to context
>>> switch between Git and svn when editing and pushing the site.
>>> 
>>> My overall goal is to find a way to automate the publishing and build of
>>> our websites either via Jenkins builds (there are some projects are
>>> doing this already when I searched infra) or the new Github actions [3].
>>> Having the site hosted in Git would make this process much easier to
>>> automate. I will need to get in touch with infra to clarify a few things
>>> and to see if this is feasible, but I think this is a worthwhile endeavor.
>>> 
>>> How do you guys feel about moving our site's repository from svn to GitBox?
>>> 
>>> Francis
>>> 
>>> 
>>> [1] https://blogs.apache.org/infra/entry/git_based_websites_available
>>> [2] https://issues.apache.org/jira/browse/INFRA-17655
>>> [3] https://github.com/features/actions
>> 

Re: CalciteRemoteDriverTest vs avatica.MetaImpl vs avatica.server.Main thread safety

[Vladimir Sitnikov]

Julian> allocate a new object per request

Josh> The Meta implementation inside of the Avatica server is a singleton,

Julian, I don't think singletones can be allocated per request.
I don't think final fields of singletones can be changed on a per-request
basis.

What's your suggestion then?

I've created https://issues.apache.org/jira/browse/CALCITE-2853
It looks like the issue was there for ages, so it does not look like a
release blocker, however the bug does break CI, and I'm tired of getting
"build's broken" mails from Apache Jenknis, especially after I commit an
innocent fix.

Vladimir

[jira] [Created] (CALCITE-2853) avatica.MetaImpl and calcite.jdbc.CalciteMetaImpl are not thread-safe

[Vladimir Sitnikov (JIRA)]

Vladimir Sitnikov created CALCITE-2853:
--

 Summary: avatica.MetaImpl and calcite.jdbc.CalciteMetaImpl are not 
thread-safe
 Key: CALCITE-2853
 URL: https://issues.apache.org/jira/browse/CALCITE-2853
 Project: Calcite
  Issue Type: Bug
  Components: avatica, core
Affects Versions: 1.18.0, avatica-1.13.0
Reporter: Vladimir Sitnikov


MetaImpl is a server-side singletone, and CalciteMetaImpl never creates 
connections.
This causes all the incoming requests to be served by a single connection only, 
and it produces in wrong results when accessed from concurrent threads (e.g. 
CalciteRemoteDriverTest in builds.apache.org).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: CalciteRemoteDriverTest vs avatica.MetaImpl vs avatica.server.Main thread safety

[Julian Hyde]

Common strategies for implementing servers using non-thread-safe objects: use 
one object and ensure only one thread uses it at a time (the actor model), 
allocate a new object per request, or (if creating an object is expensive) pool 
objects and re-use them for later requests.

> On Feb 15, 2019, at 12:47 PM, Vladimir Sitnikov  
> wrote:
> 
> Julian> Indeed, JDBC itself is not thread-safe
> 
> Just in case: CalciteRemoteDriverTest seems to be pretty sane test (it
> does not use the same java.sql.Connection across multiple threads),
> yet it fails with race-condition-like reasons.
> 
> I won't really want to dig into JDBC thread-safety, however that is a
> slippery slope. I used to think that JDBC is not thread-safe, however
> now I don't think so (after being pgjdbc maintainer for a several
> years).
> For instance, there's Connection#getWarnings, and clients expect that
> to work from a separate thread while statement is still running (and
> producing warnings).
> There's #close which apparently should be thread-safe (e.g. to play
> well with automatic flnalize-like cleanup).
> Threre's Connection#abort, and so on.
> 
> Julian> So, the solution is not necessarily to add locks and/or
> synchronized all over MetaImpl.
> 
> Apparently the solution is to replace "connection" and "connProps"
> fields of MetaImpl with Map kind of field.
> It is really hard to imagine a HTTP service that produces correct
> results only in case it is accessed from within a single connection
> only.
> 
> For instance, connectionSync is a separate wire command, so currently
> it just overwrites MetaImpl field, and it is pretty close to plug
> kind of technology.
> I wonder how it managed to survive for such a long go.
> 
> 
> I'm not sure how much sense MetaImpl(AvaticaConnection connection)
> constructor parameter makes.
> I think connection creation should happen in
> org.apache.calcite.avatica.MetaImpl#openConnection
> 
> Of course, MetaImpl might want to have a connection instance for calls
> like catalogs(), then it could just call openConnection on its own and
> that's it.
> 
> Am I missing something?
> 
> Vladimir

Re: CalciteRemoteDriverTest vs avatica.MetaImpl vs avatica.server.Main thread safety

[Vladimir Sitnikov]

Julian> Indeed, JDBC itself is not thread-safe

Just in case: CalciteRemoteDriverTest seems to be pretty sane test (it
does not use the same java.sql.Connection across multiple threads),
yet it fails with race-condition-like reasons.

I won't really want to dig into JDBC thread-safety, however that is a
slippery slope. I used to think that JDBC is not thread-safe, however
now I don't think so (after being pgjdbc maintainer for a several
years).
For instance, there's Connection#getWarnings, and clients expect that
to work from a separate thread while statement is still running (and
producing warnings).
There's #close which apparently should be thread-safe (e.g. to play
well with automatic flnalize-like cleanup).
Threre's Connection#abort, and so on.

Julian> So, the solution is not necessarily to add locks and/or
synchronized all over MetaImpl.

Apparently the solution is to replace "connection" and "connProps"
fields of MetaImpl with Map kind of field.
It is really hard to imagine a HTTP service that produces correct
results only in case it is accessed from within a single connection
only.

For instance, connectionSync is a separate wire command, so currently
it just overwrites MetaImpl field, and it is pretty close to plug
kind of technology.
I wonder how it managed to survive for such a long go.


I'm not sure how much sense MetaImpl(AvaticaConnection connection)
constructor parameter makes.
I think connection creation should happen in
org.apache.calcite.avatica.MetaImpl#openConnection

Of course, MetaImpl might want to have a connection instance for calls
like catalogs(), then it could just call openConnection on its own and
that's it.

Am I missing something?

Vladimir

Re: Failed to parse a PostgreSQL query using the Babel conformance

[Julian Hyde]

I’ve added comments to the JIRA case.

> On Feb 15, 2019, at 5:22 AM, Muhammad Gelbana  wrote:
> 
> Here is what I've done so far for CALCITE-2843
> :
> https://github.com/MGelbana/calcite/pull/1/files
> I appreciate a quick overview and guidance if I'm going in the wrong
> direction.
> 
> Thanks,
> Gelbana
> 
> 
> On Thu, Feb 14, 2019 at 5:57 PM Muhammad Gelbana 
> wrote:
> 
>> @Stamatis, I very appreciate you taking the time to comment on the issues
>> I opened basd on this thread. I'm currently going through Babel's Parser.jj
>> file and JavaCC documentations trying to understand what I need to do and
>> where.
>> 
>> Considering you're probably more acquainted than I am. I'll gladly work
>> with you on a branch to fix this, based on your instructions of course.
>> Otherwise, I'll continue working on my own.
>> 
>> Thanks,
>> Gelbana
>> 
>> 
>> On Mon, Feb 11, 2019 at 11:31 PM Muhammad Gelbana 
>> wrote:
>> 
>>> Your replies are very much appreciated. I'll see what I can do.
>>> 
>>> @Julian, I believe '=' acts as a boolean operator here because the query
>>> returns boolean results for that part of the selection.
>>> 
>>> Thanks,
>>> Gelbana
>>> 
>>> 
>>> On Mon, Feb 11, 2019 at 8:38 PM Julian Hyde  wrote:
>>> 
 There are a few Postgres-isms in that SQL:
 The “::” (as a shorthand for cast) in 'typinput='array_in'::regproc
 The ‘=‘ (as a shorthand for alias) in 'typinput='array_in'::regproc’
 Use of a table function without the ’TABLE’ keyword, in 'from
 generate_series(1, array_upper(current_schemas(false), 1))’
 
 Babel does not handle any of those right now, but it could.
 Contributions welcome.
 
 Julian
 
 
> On Feb 11, 2019, at 6:14 AM, Stamatis Zampetakis 
 wrote:
> 
> Hi Gelbana,
> 
> In order to use the Babel parser you need to also set an appropriate
> factory to your parser configuration since
> setting only the conformance is not enough.
> 
> Try adding the following:
> ...
> configBuilder().setParserFactory(SqlBabelParserImpl.FACTORY);
> 
> Having said that I am not sure if Babel can handle the syntax you
 provided.
> 
> Best,
> Stamatis
> 
> 
> 
> Στις Σάβ, 9 Φεβ 2019 στις 10:46 μ.μ., ο/η Muhammad Gelbana <
> m.gelb...@gmail.com> έγραψε:
> 
>> I'm trying to parse a PostgreSQL metadata query but a parsing
 exception is
>> thrown.
>> 
>> Here is my code:
>> 
>> Config parserConfig =
>> configBuilder().setConformance(SqlConformanceEnum.BABEL).build();
>> FrameworkConfig frameworkConfig =
>> Frameworks.newConfigBuilder().parserConfig(parserConfig).build();
>> Planner planner = Frameworks.getPlanner(frameworkConfig);
>> planner.parse("SELECT typinput='array_in'::regproc, typtype FROM
>> pg_catalog.pg_type LEFT JOIN (select ns.oid as nspoid, ns.nspname,
 r.r from
>> pg_namespace as ns join ( select s.r, (current_schemas(false))[s.r] as
>> nspname from generate_series(1, array_upper(current_schemas(false),
 1)) as
>> s(r) ) as r using ( nspname )) as sp ON sp.nspoid = typnamespace WHERE
>> typname = $1 ORDER BY sp.r, pg_type.oid DESC LIMIT 1");
>> 
>> *The exception title is* "Exception in thread "main"
>> org.apache.calcite.sql.parser.SqlParseException: Encountered ":" at
 line 1,
>> column 27."
>> 
>> Am I doing something wrong or is the parser still not ready for such
 syntax
>> ?
>> 
>> Thanks,
>> Gelbana
>> 
 
 

[GitHub] vlsi commented on issue #998: Suggestion: Improvement of Autoboxing and Unboxing

[GitBox]

vlsi commented on issue #998: Suggestion: Improvement of Autoboxing and Unboxing
URL: https://github.com/apache/calcite/pull/998#issuecomment-464091696
 
 
   @o0lwj0o , 
   
   >The other potential problem is that Java implement autoboxing and unboxing 
since JDK 1.5. If run this in low version JDK
   
   Not an issue: Calcite is Java 1.8+, so use of Java 1.4 or less is not 
supported here anyway.
   
   >I recommend use “Integer.parseInt(String)” which return type is int to 
improve its performance.
   
   Technically speaking, there's a perf difference, however it is not that big.
   See https://youtrack.jetbrains.com/issue/IDEA-207267
   
   >“double-Doubel”, “float-Float”
   
   There's no performance difference for Double and/or Float in trivial cases.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (CALCITE-2851) Simplification: track visited nodes in paranoid mode

[Zoltan Haindrich (JIRA)]

Zoltan Haindrich created CALCITE-2851:
-

 Summary: Simplification: track visited nodes in paranoid mode
 Key: CALCITE-2851
 URL: https://issues.apache.org/jira/browse/CALCITE-2851
 Project: Calcite
  Issue Type: Improvement
Reporter: Zoltan Haindrich
Assignee: Zoltan Haindrich


Idea is to have an object which could track all the visited nodes, goal is to 
identify if we have rules which are about to re-visit a previously visited node 
again.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] Move site repositories from svn to gitbox

[Michael Mior]

I think we may want to keep the old SVN repository around if this is
the case, but I personally don't have a problem with losing history in
the new git repo. On a related note, it would be good to find a
process for the new repo that can work with a shallow clone so we
don't have to have the entire history of the site to push a change.

--
Michael Mior
mm...@apache.org

Le ven. 15 févr. 2019 à 05:29, Francis Chuang
 a écrit :
>
> Hey everyone,
>
> I have now created the calcite-site repo in Gitbox. It is now available
> via Github and the Gitbox endpoint, but currently empty.
>
> I am currently trying to migrate the svn repo, but it is taking a very
> long time and eventually timed out for me. A member of the ASF infra
> team has also confirmed that it can take hours or days to complete [1].
>
> I feel that it would probably be easier if we just copy the existing
> files from the svn repo and make that the first commit in the git repo.
> This is what Kafka did for their migration [2].
>
> How important are the commits for site pushes? In my opinion it's
> probably acceptable if we lose them and start anew with the git repo as
> they do not document changes to our code base.
>
> Happy to hear your thoughts!
>
> Francis
>
> [1] https://issues.apache.org/jira/browse/INFRA-17846
> [2]
> https://github.com/apache/kafka-site/commit/ba6c994ca09629b047ab9175f882877ba03b92da
>
> On 11/02/2019 9:00 pm, Francis Chuang wrote:
> > Hey all,
> >
> > ASF project sites have the ability to use git instead of subversion as
> > their repository for web site content [1]. It has been available since
> > 2015 and appears to be quite stable. Quite a few other projects have
> > also moved their websites to git and subsequently, Gitbox (for using
> > Github as their source of truth. As an example, see the Arrow project [2].
> >
> > I myself would love to see this as I find gits interface and ux to be
> > much easier to use compared to svn. It also reduces the need to context
> > switch between Git and svn when editing and pushing the site.
> >
> > My overall goal is to find a way to automate the publishing and build of
> > our websites either via Jenkins builds (there are some projects are
> > doing this already when I searched infra) or the new Github actions [3].
> > Having the site hosted in Git would make this process much easier to
> > automate. I will need to get in touch with infra to clarify a few things
> > and to see if this is feasible, but I think this is a worthwhile endeavor.
> >
> > How do you guys feel about moving our site's repository from svn to GitBox?
> >
> > Francis
> >
> >
> > [1] https://blogs.apache.org/infra/entry/git_based_websites_available
> > [2] https://issues.apache.org/jira/browse/INFRA-17655
> > [3] https://github.com/features/actions
>

Re: Failed to parse a PostgreSQL query using the Babel conformance

[Muhammad Gelbana]

Here is what I've done so far for CALCITE-2843
:
https://github.com/MGelbana/calcite/pull/1/files
I appreciate a quick overview and guidance if I'm going in the wrong
direction.

Thanks,
Gelbana


On Thu, Feb 14, 2019 at 5:57 PM Muhammad Gelbana 
wrote:

> @Stamatis, I very appreciate you taking the time to comment on the issues
> I opened basd on this thread. I'm currently going through Babel's Parser.jj
> file and JavaCC documentations trying to understand what I need to do and
> where.
>
> Considering you're probably more acquainted than I am. I'll gladly work
> with you on a branch to fix this, based on your instructions of course.
> Otherwise, I'll continue working on my own.
>
> Thanks,
> Gelbana
>
>
> On Mon, Feb 11, 2019 at 11:31 PM Muhammad Gelbana 
> wrote:
>
>> Your replies are very much appreciated. I'll see what I can do.
>>
>> @Julian, I believe '=' acts as a boolean operator here because the query
>> returns boolean results for that part of the selection.
>>
>> Thanks,
>> Gelbana
>>
>>
>> On Mon, Feb 11, 2019 at 8:38 PM Julian Hyde  wrote:
>>
>>> There are a few Postgres-isms in that SQL:
>>> The “::” (as a shorthand for cast) in 'typinput='array_in'::regproc
>>> The ‘=‘ (as a shorthand for alias) in 'typinput='array_in'::regproc’
>>> Use of a table function without the ’TABLE’ keyword, in 'from
>>> generate_series(1, array_upper(current_schemas(false), 1))’
>>>
>>> Babel does not handle any of those right now, but it could.
>>> Contributions welcome.
>>>
>>> Julian
>>>
>>>
>>> > On Feb 11, 2019, at 6:14 AM, Stamatis Zampetakis 
>>> wrote:
>>> >
>>> > Hi Gelbana,
>>> >
>>> > In order to use the Babel parser you need to also set an appropriate
>>> > factory to your parser configuration since
>>> > setting only the conformance is not enough.
>>> >
>>> > Try adding the following:
>>> > ...
>>> > configBuilder().setParserFactory(SqlBabelParserImpl.FACTORY);
>>> >
>>> > Having said that I am not sure if Babel can handle the syntax you
>>> provided.
>>> >
>>> > Best,
>>> > Stamatis
>>> >
>>> >
>>> >
>>> > Στις Σάβ, 9 Φεβ 2019 στις 10:46 μ.μ., ο/η Muhammad Gelbana <
>>> > m.gelb...@gmail.com> έγραψε:
>>> >
>>> >> I'm trying to parse a PostgreSQL metadata query but a parsing
>>> exception is
>>> >> thrown.
>>> >>
>>> >> Here is my code:
>>> >>
>>> >> Config parserConfig =
>>> >> configBuilder().setConformance(SqlConformanceEnum.BABEL).build();
>>> >> FrameworkConfig frameworkConfig =
>>> >> Frameworks.newConfigBuilder().parserConfig(parserConfig).build();
>>> >> Planner planner = Frameworks.getPlanner(frameworkConfig);
>>> >> planner.parse("SELECT typinput='array_in'::regproc, typtype FROM
>>> >> pg_catalog.pg_type LEFT JOIN (select ns.oid as nspoid, ns.nspname,
>>> r.r from
>>> >> pg_namespace as ns join ( select s.r, (current_schemas(false))[s.r] as
>>> >> nspname from generate_series(1, array_upper(current_schemas(false),
>>> 1)) as
>>> >> s(r) ) as r using ( nspname )) as sp ON sp.nspoid = typnamespace WHERE
>>> >> typname = $1 ORDER BY sp.r, pg_type.oid DESC LIMIT 1");
>>> >>
>>> >> *The exception title is* "Exception in thread "main"
>>> >> org.apache.calcite.sql.parser.SqlParseException: Encountered ":" at
>>> line 1,
>>> >> column 27."
>>> >>
>>> >> Am I doing something wrong or is the parser still not ready for such
>>> syntax
>>> >> ?
>>> >>
>>> >> Thanks,
>>> >> Gelbana
>>> >>
>>>
>>>

Re: Use of noDag parameter in HepPlanner

[Stamatis Zampetakis]

FYI, what I concluded by going through the code and the various test cases
is the following.

By allowing DAGs the planner can detect common sub expressions in queries
and re-use an existing result without re-applying a rule if that is not
necessary. This should lead to fewer object creations and rule
applications, which may in turn lead to improved performance. In the
existing use cases noDag=false should appear more often since it is the
default value for two out of three constructors in the HepPlanner.

In principle it seems that using or not using DAGs should give the same
expression in the end so I would say that using DAGs is always a better
option. I tried setting noDag to be always true but various test fail with
StackOverflowError so it seems there are rules who tend to execute infinite
number of times as a result of this change. I would tend to thing that this
is a bug but I didn't look further.

Στις Τρί, 12 Φεβ 2019 στις 9:35 μ.μ., ο/η Julian Hyde 
έγραψε:

> I don’t recall.
>
> Could you review the tests and see whether tests tend to use noDag=true or
> false most of the time? Are there any tests that use the less popular
> value, and if so, is there a particular reason that those tests use that
> option?
>
> Julian
>
>
> > On Feb 12, 2019, at 6:47 AM, Stamatis Zampetakis 
> wrote:
> >
> > Hi all,
> >
> > I don't understand what is the correct way to set the noDag [1] parameter
> > in HepPlanner. I understand what it does (internal query graph becomes a
> > tree or a DAG) but I don't see why should I use the one or the other and
> > when.
> >
> > Is it performance related?
> > Are there implications on the rules that can be used with the planner?
> > Does it limit the class of queries that need to be transformed?
> >
> > Thanks in advance,
> > Stamatis
> >
> > [1]
> >
> https://github.com/apache/calcite/blob/883666929478aabe07ee5b9e572c43a6f1a703e2/core/src/main/java/org/apache/calcite/plan/hep/HepPlanner.java#L131
>
>

Re: [DISCUSS] Move site repositories from svn to gitbox

[Francis Chuang]

Hey everyone,

I have now created the calcite-site repo in Gitbox. It is now available 
via Github and the Gitbox endpoint, but currently empty.


I am currently trying to migrate the svn repo, but it is taking a very 
long time and eventually timed out for me. A member of the ASF infra 
team has also confirmed that it can take hours or days to complete [1].


I feel that it would probably be easier if we just copy the existing 
files from the svn repo and make that the first commit in the git repo. 
This is what Kafka did for their migration [2].


How important are the commits for site pushes? In my opinion it's 
probably acceptable if we lose them and start anew with the git repo as 
they do not document changes to our code base.


Happy to hear your thoughts!

Francis

[1] https://issues.apache.org/jira/browse/INFRA-17846
[2] 
https://github.com/apache/kafka-site/commit/ba6c994ca09629b047ab9175f882877ba03b92da


On 11/02/2019 9:00 pm, Francis Chuang wrote:

Hey all,

ASF project sites have the ability to use git instead of subversion as 
their repository for web site content [1]. It has been available since 
2015 and appears to be quite stable. Quite a few other projects have 
also moved their websites to git and subsequently, Gitbox (for using 
Github as their source of truth. As an example, see the Arrow project [2].


I myself would love to see this as I find gits interface and ux to be 
much easier to use compared to svn. It also reduces the need to context 
switch between Git and svn when editing and pushing the site.


My overall goal is to find a way to automate the publishing and build of 
our websites either via Jenkins builds (there are some projects are 
doing this already when I searched infra) or the new Github actions [3]. 
Having the site hosted in Git would make this process much easier to 
automate. I will need to get in touch with infra to clarify a few things 
and to see if this is feasible, but I think this is a worthwhile endeavor.


How do you guys feel about moving our site's repository from svn to GitBox?

Francis


[1] https://blogs.apache.org/infra/entry/git_based_websites_available
[2] https://issues.apache.org/jira/browse/INFRA-17655
[3] https://github.com/features/actions

[jira] [Created] (CALCITE-2849) Your project apache/calcite is using buggy third-party libraries [WARNING]

[Kaifeng Huang (JIRA)]

Kaifeng Huang created CALCITE-2849:
--

 Summary: Your project apache/calcite is using buggy third-party 
libraries [WARNING]
 Key: CALCITE-2849
 URL: https://issues.apache.org/jira/browse/CALCITE-2849
 Project: Calcite
  Issue Type: Bug
Reporter: Kaifeng Huang
Assignee: Julian Hyde



Hi, there!

We are a research team working on third-party library analysis. We have 
found that some widely-used third-party libraries in your project have 
major/critical bugs, which will degrade the quality of your project. We highly 
recommend you to update those libraries to new versions.

We have attached the buggy third-party libraries and corresponding jira 
issue links below for you to have more detailed information.

1. org.apache.httpcomponents httpclient
version: 4.5.6

Jira issues:
Support relatively new HTTP 308 redirect - RFC7538
affectsVersions:3.1 (end of life),4.5.6

https://issues.apache.org/jira/projects/HTTPCLIENT/issues/HTTPCLIENT-1946?filter=allopenissues


2. org.apache.commons commons-lang3
version: 3.8

Jira issues:
Restore BundleSymbolicName / regression in version 3.8.0
affectsVersions:3.8

https://issues.apache.org/jira/projects/LANG/issues/LANG-1419?filter=allopenissues


3. commons-io commons-io
version: 2.4

Jira issues:
IOUtils copyLarge() and skip() methods are performance hogs
affectsVersions:2.3;2.4

https://issues.apache.org/jira/projects/IO/issues/IO-355?filter=allopenissues
CharSequenceInputStream#reset() behaves incorrectly in case when buffer 
size is not dividable by data size
affectsVersions:2.4

https://issues.apache.org/jira/projects/IO/issues/IO-356?filter=allopenissues
[Tailer] InterruptedException while the thead is sleeping is silently 
ignored
affectsVersions:2.4

https://issues.apache.org/jira/projects/IO/issues/IO-357?filter=allopenissues
IOUtils.contentEquals* methods returns false if input1 == input2; 
should return true
affectsVersions:2.4

https://issues.apache.org/jira/projects/IO/issues/IO-362?filter=allopenissues
Apache Commons - standard links for documents are failing
affectsVersions:2.4

https://issues.apache.org/jira/projects/IO/issues/IO-369?filter=allopenissues
FileUtils.sizeOfDirectoryAsBigInteger can overflow
affectsVersions:2.4

https://issues.apache.org/jira/projects/IO/issues/IO-390?filter=allopenissues
Regression in FileUtils.readFileToString from 2.0.1
affectsVersions:2.1;2.2;2.3;2.4

https://issues.apache.org/jira/projects/IO/issues/IO-453?filter=allopenissues
Correct exception message in FileUtils.getFile(File; String...)
affectsVersions:2.4

https://issues.apache.org/jira/projects/IO/issues/IO-479?filter=allopenissues
org.apache.commons.io.FileUtils#waitFor waits too long
affectsVersions:2.4

https://issues.apache.org/jira/projects/IO/issues/IO-481?filter=allopenissues
FilenameUtils should handle embedded null bytes
affectsVersions:2.4

https://issues.apache.org/jira/projects/IO/issues/IO-484?filter=allopenissues
Exceptions are suppressed incorrectly when copying files.
affectsVersions:2.4;2.5

https://issues.apache.org/jira/projects/IO/issues/IO-502?filter=allopenissues


4. org.apache.logging.log4j log4j-core
version: 2.11.0

Jira issues:
Log4j2 throws NoClassDefFoundError in Java 9
affectsVersions:2.10.0;2.11.0

https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2129?filter=allopenissues
Empty Automatic-Module-Name Header
affectsVersions:2.10.0;2.11.0;3.0.0

https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2254?filter=allopenissues
gc-free mixed async loging loses parameter values after the first 
appender
affectsVersions:2.11.0

https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2301?filter=allopenissues
Log4j 2.10+not working with SLF4J 1.8 in OSGI environment
affectsVersions:2.10.0;2.11.0

https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2305?filter=allopenissues
AsyncQueueFullMessageUtil causes unparsable message output
affectsVersions:2.11.0

https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2318?filter=allopenissues
AbstractLogger NPE hides actual cause when getFormat returns null
affectsVersions:2.11.0

https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2320?filter=allopenissues
AsyncLogger without specifying a level always uses ERROR
affectsVersions:2.11.0