We currently maintain a release cadence of a new release every two
months. This puts the next release pretty close to Christmas next month.
Would it make sense if we push 1.27.0 back a few weeks until maybe after
new year? In the mean time, perhaps we can focus on getting these issues
fixed and improve the reliability of search/sarge? Perhaps even to the
extent where we divert some resources from other features and put more
focus into search/sarge.
Francis
On 17/11/2020 5:38 am, Julian Hyde wrote:
And yet more passive-aggressive bulls**t from Vladimir:
https://github.com/apache/calcite/commit/c6b3fb7ddbf8aed981ff3fb0632c77216dbe68d6
I've force-pushed to remove it.
I plan to respond to Stamatis' thoughtful email later today. Also, I
think I may have a test case that demonstrates the issues that
Vladimir is talking about; if so, I'll log a JIRA case. But for now, I
need to get on with my work week.
Julian
On Mon, Nov 16, 2020 at 3:28 AM Vladimir Sitnikov
<sitnikov.vladi...@gmail.com> wrote:
Stamatis>@Vladimir: Can you specify which JIRA issue(s) you would like to
see solved
Stamatis>for the next release?
RexProgramFuzzyTest should be enabled, and Sarg-related fuzzing should be
implemented as well.
RexFuzzer should generate Sarg expressions.
RexInterpreter should be able to evaluate search/sarg.
RexProgramFuzzyTest should pass both with and without expandSearch.
I'm afraid I have no time on executing RexProgramFuzzyTest and logging
failures as JIRA cases.
I assume committers should ensure the code they commit passes existing
tests, and they should ensure new code is accompanied by tests as well.
It looks like I tried everything:
a) I kindly asked Julian to refrain from committing untested code (both in
PR and in the very first message of the thread)
b) I highlighted major design issues (see unknownAs in [1])
c) I provided sample failures (see "sample input" in [2])
d) I even suggested the plan to resolve the issues: "revert search/sarg",
"re-enable fuzzer", "fix issues discovered by the fuzzer", "re-add
search/sarg".
Not only I suggested the approach, I implemented a noticeable part of it
(e.g.I re-enabled the fuzzer and added relevant code fixes to make the test
pass, see CALCITE-4398, CALCITE-4397, CALCITE-4388), however, Julian
discarded all of it with "A commit war is no way to proceed" comment.
Now I stop doing everything related to search/sarg.
Of course, if there's a release, and the fuzzer is still disabled, I would
put my -1 vote.
[1]
https://lists.apache.org/thread.html/r602b7e17cf076f00dfbd946e814cea098a7b81e0b252bfa6e2fd5e9b%40%3Cdev.calcite.apache.org%3E
[2]
https://lists.apache.org/thread.html/r6d509f7202195362b33f93c076b5010bd1a9a5ac1e4fa6814819077c%40%3Cdev.calcite.apache.org%3E
Vladimir
