Re: CALCITE-2458 Use of Kotlin for unit tests
Apache/voting> A decision-making policy which assumes general consent if no
are posted within a defined period.
Does that mean "absolutely no responses"? I hope no.
Does that mean "a single -0 comment destroys lazy consensus"? I hope no.
Does that mean "a single +0 comment destroys lazy consensus"? I hope no.
Does that mean "any vote less than +1 kills the idea"? I hope no.
I read "lazy consensus" more like "whoever does not object counts as the
one who approves the idea".
E.g. in OpenOffice they even suggest to just commit things and roll back
later if there are objections:
OpenOffice/lazyConsensus>We have a time machine (Subversion), this means
that as long as you commit (or submit patches) early and often the
community has plenty of opportunity to indicate disapproval
Michael>some with reasonable objections
Michael, I can go one by one and discuss each and every "objection",
however they do sound very weak.
On the other hand, the expression was "-0" in most of the cases which I
read as "fear of unknown" rather than true objection.
Just a bit of an example: Calcite codebase has "Pig" adapter. The tests
there are written in, well, Pig language.
Was there a all-way-long-research regarding the possibility of inclusion of
Pig language to Calcite codebase?
I'm sure there were zero researches given.
Do Pig test disturb Calcite community? Of course it does.
CI Job fails every now and then (see
https://issues.apache.org/jira/browse/CALCITE-1598, etc, etc)
Even current CI Job fails VERY often due to some weird results of Pig tests.
This greatly reduces the value of Apache Jenkins build reports.
The strongest negative vote was from Jacques whose "standard response is -1
to introducing new languages".
I wonder what Jacques would say regarding "Pig language introduction to
Does "Pig language" create a barrier for contributors? I doubt so. Pig is
invisible to most of the contributors as long as the tests pass.
Unfortunately, Pig fails the build extremely often in builds.apache.org.
As you might know, I've created mat-calcite-plugin, and my co-workers use
that tool quite often to analyze Java heap dumps when they troubleshoot OOM
and issues alike.
Of course they happen to run into Calcite defects/glitches, and what they
say me is they struggle/fear to touch Calcite codebase for the following
1) Existing tests are quite cryptic. Quidem is something that is hard to
understand for a person with Java/SQL background.
2) It is not clear how to create a "simple" test case. It's not clear where
the test belongs, what are the options, and so on.
I can continue. I don't really have intention to blame specific parts of
the codebase (especially the code I've created :) ), however I don't buy
"Kotlin might impose a barrier for contributors" as a true objection.
Kotlin is much closer to Java than say Pig/Cassandra/Geode/CSV.
If Kotlin required a specific/cryptic setup from the contributor, then, yes
it would be an strong objection to consider.
If Kotlin reduced build times twice, then it would again be a strong
However, there was not a single strong objection given.
Could we please stop making fuzz out of thin air like "voting whether
should we enable use of Kotlin in unit tests or not" and proceed with
PS. I do remember "vetoing" case is still pending, and it was a simple case
with trivial technical reasoning.
Of course current case is a bit more complicated, however "Kotlin for
tests" is very safe bet.