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 mm...@apache.org Le mar. 25 sept. 2018 à 16:41, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> 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 >
