I share the concerns raised by Stamatis and Haisheng. I understand the motivations behind Vladimir's decision, I would not oppose a revert but I'm not 100% sure at this point it is the best approach. I would lean towards creating bug tickets in Jira describing the known issues, with version "1.27" and priority "blocker", work on them and when the release date approaches re-evaluate the situation (if they are not solved by then, then revert).
Best regards, Ruben On Fri, Nov 13, 2020 at 6:03 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > I see there is a desire to keep SEARCH in the next release. > I see there's a silence as well (e.g. some committers/PMCs are not > replying) which is understandable. > > However, there's even more: Danny and Julian commit more changes/features > to search/sarg feature. > I guess it was unintentional, however, Julian committed CALCITE-4383 and > CALCITE-4389. The commits depend on SEARCH code, so I can't really revert > SEARCH and keep 4383/4389 at the same time (e.g. the new changes > modify SqlInternalOperators which was added in "Add internal SEARCH > operator" commit) > > So I would have to revert some of the recent commits as well :( > > Vladimir >
