I didn't aim to accuse anyone of the fact that those Jiras weren't accepted in my previous letter, sorry if it was interpreted in that way. I just explained why we still use fork.
Regarding 'big messy changes that are of obvious benefit only to the contributor', at least CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> is a problem that worries not only Drill. For example, recently was logged CALCITE-2538 <https://issues.apache.org/jira/browse/CALCITE-2538> with the same bug. Kind regards, Volodymyr Vysotskyi On Thu, Sep 13, 2018 at 3:25 AM Julian Hyde <[email protected]> wrote: > Yes, this is a feature that could be enabled based on a SqlConformance > property. > > However we would also need to agree semantics (probably based on other > databases that have similar functionality), add tests, and make the > functions work in Calcite’s default function implementations. > > Julian > > > On Sep 12, 2018, at 5:18 PM, Chunhui Shi <[email protected]> > wrote: > > > > For CALCITE-1178 and other loosing type check things, if the concern was > that it is not compliant with SQL standard, should this be a SQL flavor > defined in one of compliance? So Calcite users (e.g. Drill) can choose a > customized compliance to enable the implicit type conversion. > > ------------------------------------------------------------------ > > Sender:Julian Hyde <[email protected]> > > Sent at:2018 Sep 12 (Wed) 17:04 > > To:dev <[email protected]> > > Cc:dev <[email protected]> > > Subject:Re: Publish Drill Calcite project artifacts to Apache maven > repository > > > > Probably down to me. Although, in my defense, it is hard to be > gatekeeper for big messy changes that are of obvious benefit to the > contributor but not such obvious benefit to the rest of the project. > > > > Is there a PR for CALCITE-1178? > > > > Julian > > > > > >> On Sep 12, 2018, at 10:32 AM, Vova Vysotskyi <[email protected]> wrote: > >> > >> Thanks for your responses and clarifications! > >> > >> Regarding the reasons for using the fork: > >> We would love to move to the Apache Calcite instead of using the fork! > >> > >> And we tried very hard to do it, especially during the rebase from 1.4 > to > >> 1.15 (DRILL-3993 <https://issues.apache.org/jira/browse/DRILL-3993>). > >> But unfortunately, there left three Jiras, which weren't accepted by the > >> Calcite community yet: > >> CALCITE-2087 <https://issues.apache.org/jira/browse/CALCITE-2087>, > >> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and > >> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>. > >> > >> Kind regards, > >> Volodymyr Vysotskyi > >> > >> > >> On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde <[email protected]> wrote: > >> > >>> I can confirm what Josh says about OSSRH. You need to fill out a form > with > >>> Sonatype that convinces them that you own the groupId (basically a > domain > >>> name). Then they give you authorization to publish artifacts under that > >>> groupId. For example, I publish artifacts under the sqlline and > >>> net.hydromatic groupIds. > >>> > >>>> On Sep 12, 2018, at 9:28 AM, Josh Elser <[email protected]> wrote: > >>>> > >>>> Maven central is made up of a number of "Trusted" Maven repositories. > >>> This includes the ASF and OSSRH Maven repositories. Many other > >>> organizations run "mirrors" of central. > >>>> > >>>> The ASF Maven repo is published to by ASF projects who have gone > through > >>> the ASF release process. OSSRH allows any release which meets the > criteria > >>> described here[1]. As an individual, you are within your rights to > publish > >>> your fork of Calcite to OSSRH as long as there are no legal or > trademark > >>> concerns. It would be imperative to not cause confusion with official > >>> Apache Calcite releases -- clear branding and separate Maven > >>> groupId/artifactId "coordinates" should be sufficient. > >>>> > >>>> However, since you are (presumably) acting as a member of Apache > Drill, > >>> it would be very odd (and potentially against ASF policy) to make a > release > >>> of software that *isn't* using the ASF Maven resources. This gives me > some > >>> pause -- do you have an ASF member on your PMC you can run this by? > >>>> > >>>> Finally, as a Calcite PMC member, I feel obligated to ask why Drill > >>> needs to maintain this fork, and see if there is something that can be > done > >>> from the Calcite side to get you "back on upstream"? Why the need to > make > >>> long-term plans to isolate Apache Drill from Apache Calcite? > >>>> > >>>> [1] https://central.sonatype.org/pages/ossrh-guide.html > >>>> > >>>> On 9/12/18 11:33 AM, Vova Vysotskyi wrote: > >>>>> Hi all, > >>>>> As you know, Drill uses its fork of Apache Calcite. > >>>>> In DRILL-6711 <https://issues.apache.org/jira/browse/DRILL-6711> was > >>>>> proposed to deploy Drill Calcite project artifacts > >>>>> to Apache Maven repository or at least to the central maven > repository. > >>>>> I have looked for the similar cases of fork versions and didn't find > >>>>> anything similar in the central repo. > >>>>> Also, I have looked at the Sonatype OSSRH Jiras for similar cases > >>>>> of deploying fork versions, but that projects used custom groupIds. > >>>>> Could someone please give me the advice what is the acceptable way > >>>>> of publishing the custom Drill Calcite artifacts to the central repo > and > >>>>> is it possible to publish them without changing groupId? > >>>>> Kind regards, > >>>>> Volodymyr Vysotskyi > >>> > >
