[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CALCITE-2458 Use of Kotlin for unit tests

1) I don't really understand the comparison with Pig. Calcite has a Pig
adapter as a feature and writing tests in Pig is necessary to support that
feature. (Same is true with other adapters.) That's not the case with
Kotlin. If Calcite had a Kotlin API as a feature, of course we would have
Kotlin code.

2) I'm surprised that others find the quidem tests cryptic but if anything,
this seems to be another argument against Kotlin.

> 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
> development?

I'm not sure who was calling for a vote (I wasn't and I haven't seen that
in this thread) but there seem to be others who don't see this as "out of
thin air." I still maintain my +0.5 and I'm fine with the change but I
think if we're going to use the term "lazy consensus" we should agree on
what it means.

Michael Mior

Le mar. 25 sept. 2018 à 16:41, Vladimir Sitnikov <
sitnikov.vladimir@xxxxxxxxx> a écrit :

> Apache/voting> A decision-making policy which assumes general consent if no
> responses
> 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:
> https://openoffice.apache.org/docs/governance/lazyConsensus.html
> 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.
> Ex1)
> 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-1751,
> 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
> Calcite codebase".
> 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.
> Ex2)
> Quidem.
> 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
> reasons:
> 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
> objection.
> 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
> development?
> 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.
> Vladimir