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
