Don’t worry, I didn’t feel accused. I know you Drill folks are in pain because you’re on a fork. I was empathizing with your pain. And I know that when a block a PR it causes the pain to continue.
> On Sep 13, 2018, at 2:12 AM, Vova Vysotskyi <vvo...@gmail.com> wrote: > > 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 <jh...@apache.org> 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 <shi.chun...@aliyun.com.INVALID> >> 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 <jh...@apache.org> >>> Sent at:2018 Sep 12 (Wed) 17:04 >>> To:dev <d...@calcite.apache.org> >>> Cc:dev <dev@drill.apache.org> >>> 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 <vvo...@gmail.com> 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 <jh...@apache.org> 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 <els...@apache.org> 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 >>>>> >> >>
