On Thu, Jul 4, 2019 at 9:25 AM Jacques Nadeau <jacq...@apache.org> wrote: > > On Thu, Jul 4, 2019, 7:05 AM Wes McKinney <wesmck...@gmail.com> wrote: > > > hi Jacques, > > > > I agree that we should allow ample time for discussions around issues > > raised by people validating the release. > > > > That is the main point here. There should have been a discussion about > this. Different people are expecting different things out of Arrow and all > perspectives should be considered. > > > > That being said, with Ryan's issue, he is using a feature > > (cross-language auth in Flight) that isn't being tested. The Flight > > integration tests do not use authentication AFAIK so I'm not surprised > > to hear that there may be an issue with it. It would be as if there > > were a cross-compatibility issues between Python and Rust. Again, > > would not surprise me because Rust is not included in the integration > > tests. Even with a reproduction of such an issue I don't think it > > should block the release in the future. > > > > By definition, issues we find during the release are things we didn't know > about before the release and either have no test or tests that failed to > run. Having to be a regression or existing failing tests is too low a bar. > If we figured out that there was major incompatibility between Rust and > Python that would also warrant serious discussion even if there is a lack > of integration tests. The discussion is where we figure these things out, > not in a set of easily defined rules. >
I agree that we expect at least a 24 hour window for further discussion when issues come up. I hope this episode will serve as a learning opportunity for the community -- we are all working toward the same goals of progress and innovation. There are a huge number of hungry mouths to feed with this project; I've been having tons of people contacting me offline about timeline for this release also. Personally, I think the principle solution here is to release more often and to only block releases in the event of critical brokenness (like an entire language library being fundamentally unusable). Having 2-3 months between major releases is creating too much pressure on both the developer and user community. If releases were reliably coming out once a month it would be better for everyone. > > > > I'd be glad to help make a point release in the near future since we > > uncovered quite a few small issues during this RC, and I think there's > > more value in getting the software into the hands of users than > > waiting multiple weeks to address them all. > > > > Appreciated and needed. I've talked to 20+ companies in the last several > weeks anxiously awaiting use of this Fight release. If this problem exists > (still want to see reproduction), this makes the flight release unusable > for the use case they wanted to leverage it for. > Great. I think we need to have someone new be the next RM. For the record, here is the record of mainline release managers so far: Julien: 0.1.0 Uwe: 0.2.0, 0.12.1 Wes: 0.3.0, 0.4.0, 0.4.1, 0.5.0, 0.6.0, 0.7.0, 0.7.1, 0.8.0, 0.9.0, 0.11.1 Phillip C: 0.10.0 Kou: 0.11.0, 0.13.0, 0.14.0 Krisztian: 0.12.0 (I was also the RM for 5 JavaScript releases) > > > > > > On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau <jacq...@apache.org> wrote: > > > > > > A release vote should last until we arrive at consensus. When an issue is > > > potentially identified, those that have voted should be given ample time > > to > > > change their vote and others that may have been lazy consenters should be > > > given time to chime in. There is no maximum amount of time a vote can be > > > open. Allowing at least 24 hours after an objection is raised is a pretty > > > minimum expectation unless the objector removes their objection. > > > > > > Note that Apache is more focused on consensus than timing (as opposed to > > > virtually other other organizations in the world). > > > > > > In this case I was waiting to see more information from the objector > > before > > > casting my vote. I see a -1 vote as community chilling and prefer for > > > consensus to be reached through discussions rather than contrary voting. > > > > > > > > > > > > On Thu, Jul 4, 2019, 6:35 AM Antoine Pitrou <anto...@python.org> wrote: > > > > > > > > > > > That's an open question. How long should a release vote last? > > > > Apparently this one lasted 3 days. The 0.14.0 vote (after RC4) lasted > > 3 > > > > days before a decision was made too. > > > > > > > > Regards > > > > > > > > Antoine. > > > > > > > > > > > > Le 04/07/2019 à 15:28, Jacques Nadeau a écrit : > > > > > There are two different questions here. > > > > > > > > > > 1) should this issue block the release. > > > > > 2) should a discussion with ample time for all parties to come to > > > > consensus > > > > > have occurred before closing the vote. > > > > > > > > > > The first question is a subjective question. The answer to the second > > > > > question should have been an unequivocal yes. > > > > > > > > > > I'll send a separate mail on point one but the problem I see here > > > > > fundamentally is point two. > > > > > > > > > > On Thu, Jul 4, 2019, 6:01 AM Antoine Pitrou <anto...@python.org> > > wrote: > > > > > > > > > >> > > > > >> I agree with Kou here. It's not a problem with the release per se, > > it's > > > > >> a problem with the Flight code in git master. There is no > > regression > > > > >> AFAICT, and we have not promised that Flight was stable and > > > > >> production-ready yet. > > > > >> > > > > >> If we're ok releasing with bugs such as this (Java unable to read > > back > > > > >> union arrays?), then I think a Flight bug shouldn't hold a release. > > > > >> https://issues.apache.org/jira/browse/ARROW-5231 > > > > >> > > > > >> Regards > > > > >> > > > > >> Antoine. > > > > >> > > > > >> > > > > >> Le 04/07/2019 à 14:46, Jacques Nadeau a écrit : > > > > >>> Im disappointed in this response. When someone finds an issue with > > a > > > > >>> release it should be triaged/validated rather than rushed past > > rather > > > > >>> quickly and closing the vote before others can chime in on the > > issue. > > > > >>> > > > > >>> I'm now left voting -1 on a closed vote. In the future, let's have > > a > > > > >>> discussion about issues like this. Your response and the close of > > the > > > > >> vote > > > > >>> were unilateral and all happened while some of us were sleeping. > > > > >>> > > > > >>> On Wed, Jul 3, 2019, 10:47 PM Sutou Kouhei <k...@clear-code.com> > > wrote: > > > > >>> > > > > >>>> Hi, > > > > >>>> > > > > >>>> Flight isn't stable yet. So Flight problem isn't a blocker > > > > >>>> of this release. Could you open a JIRA issue for your > > > > >>>> problem? We'll be able to fix it until 1.0.0. > > > > >>>> > > > > >>>> > > > > >>>> Thanks, > > > > >>>> -- > > > > >>>> kou > > > > >>>> > > > > >>>> In < > > > > cakg4kdx8_rr8xqobaspw+u0lypx21tpcwx6s4_rddmk4vpd...@mail.gmail.com> > > > > >>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul > > 2019 > > > > >>>> 17:18:15 -0700, > > > > >>>> Ryan Murray <rym...@dremio.com> wrote: > > > > >>>> > > > > >>>>> Hi All, > > > > >>>>> > > > > >>>>> I have noticed that a python Flight client can't authenticate to > > a > > > > Java > > > > >>>>> Flight server while doing some testing today. I am trying to > > confirm > > > > if > > > > >>>>> this is a bug in the flight implementation or in my own code. I > > > > >> thought I > > > > >>>>> would report here as it could potentially be a blocker to this > > > > release. > > > > >>>>> > > > > >>>>> I will confirm and come back to you shortly. > > > > >>>>> > > > > >>>>> Best, > > > > >>>>> Ryan > > > > >>>>> > > > > >>>>> On Wed, Jul 3, 2019 at 5:02 PM Sutou Kouhei <k...@clear-code.com> > > > > >> wrote: > > > > >>>>> > > > > >>>>>> Thanks for confirming it! > > > > >>>>>> > > > > >>>>>> This will be solved by the pull request. > > > > >>>>>> > > > > >>>>>> In < > > > > >> caf6ot1d5x-gledlhbaixi74+pxo5ap8eggsylwquimwpvxm...@mail.gmail.com> > > > > >>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul > > 2019 > > > > >>>>>> 13:53:19 -0700, > > > > >>>>>> Chao Sun <sunc...@apache.org> wrote: > > > > >>>>>> > > > > >>>>>>> Thanks Sutou. It is 2.5.0: > > > > >>>>>>> > > > > >>>>>>> $ protoc --version > > > > >>>>>>> libprotoc 2.5.0 > > > > >>>>>>> > > > > >>>>>>> Yes this is an old version, which is still used by Apache > > Hadoop. > > > > >>>>>>> > > > > >>>>>>> On Wed, Jul 3, 2019 at 1:27 PM Sutou Kouhei < > > k...@clear-code.com> > > > > >>>> wrote: > > > > >>>>>>> > > > > >>>>>>>> Thanks for verifying this RC! > > > > >>>>>>>> > > > > >>>>>>>> It seems that the C++ error is caused by old Protocol > > > > >>>>>>>> Buffers. Could you show your system Protocol Buffers > > > > >>>>>>>> version? > > > > >>>>>>>> > > > > >>>>>>>> https://github.com/apache/arrow/pull/4785 will resolve this > > > > >>>>>>>> case. It prevents using old system Protocol Buffers. > > > > >>>>>>>> > > > > >>>>>>>> In < > > > > >>>> > > caf6ot1e8emh1gwooo+uuq5z6amwzprfuuyv4c+w+crpievz...@mail.gmail.com> > > > > >>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul > > > > 2019 > > > > >>>>>>>> 00:15:54 -0700, > > > > >>>>>>>> Chao Sun <sunc...@apache.org> wrote: > > > > >>>>>>>> > > > > >>>>>>>>> On MacOS Mojave. Verified Rust and Go with > > > > >>>> verify-release-candidate.sh > > > > >>>>>>>> and > > > > >>>>>>>>> they look good. > > > > >>>>>>>>> I got the following error when verifying C++ though: > > > > >>>>>>>>> > > > > >>>>>>>>> [ 18%] Built target grpc_dependencies > > > > >>>>>>>>> CMake Error at > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-RELEASE.cmake:49 > > > > >>>>>>>>> (message): > > > > >>>>>>>>> Command failed: 2 > > > > >>>>>>>>> '/Library/Developer/CommandLineTools/usr/bin/make' > > > > >>>>>>>>> See also > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep-stamp/orc_ep-build-*.log > > > > >>>>>>>>> make[2]: *** [orc_ep-prefix/src/orc_ep-stamp/orc_ep-build] > > Error > > > > 1 > > > > >>>>>>>>> make[1]: *** [CMakeFiles/orc_ep.dir/all] Error 2 > > > > >>>>>>>>> > > > > >>>>>>>>> In orc_ep-build-err.log: > > > > >>>>>>>>> > > > > >>>>>>>>> In file included from > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > /var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20: > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:59:18: > > > > >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'WriteAliasedRaw' marked > > > > >>>>>> 'override' > > > > >>>>>>>>> but does not override any member functions^[[0m > > > > >>>>>>>>> virtual bool WriteAliasedRaw(const void * data, int size) > > > > >>>>>> override; > > > > >>>>>>>>> ^[[0;1;32m ^ > > > > >>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > ^[[0m^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mm0000gn/T/arrow-0.14.0.XXXXX.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.hh:60:18: > > > > >>>>>>>>> ^[[0m^[[0;1;31merror: ^[[0m^[[1m'AllowsAliasing' marked > > > > 'override' > > > > >>>>>> but > > > > >>>>>>>>> does not override any member functions^[[0m > > > > >>>>>>>>> virtual bool AllowsAliasing() const override; > > > > >>>>>>>>> ^[[0;1;32m ^ > > > > >>>>>>>>> ^[[0m2 errors generated. > > > > >>>>>>>>> make[5]: *** > > [c++/src/CMakeFiles/orc.dir/io/OutputStream.cc.o] > > > > >>>> Error 1 > > > > >>>>>>>>> make[4]: *** [c++/src/CMakeFiles/orc.dir/all] Error 2 > > > > >>>>>>>>> make[3]: *** [all] Error 2 > > > > >>>>>>>>> > > > > >>>>>>>>> Not sure if this is due to my environment. > > > > >>>>>>>>> > > > > >>>>>>>>> Chao > > > > >>>>>>>>> > > > > >>>>>>>>> On Tue, Jul 2, 2019 at 6:54 PM Ravindra Pindikura < > > > > >>>>>> ravin...@dremio.com> > > > > >>>>>>>>> wrote: > > > > >>>>>>>>> > > > > >>>>>>>>>> ok, thanks ! > > > > >>>>>>>>>> > > > > >>>>>>>>>> On Wed, Jul 3, 2019 at 7:10 AM Sutou Kouhei < > > k...@clear-code.com > > > > > > > > > >>>>>> wrote: > > > > >>>>>>>>>> > > > > >>>>>>>>>>> Hi, > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> Thanks for verifying this RC! > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>> 2. The package doesn't seem to include gandiva > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just > > > > >>>> want > > > > >>>>>> to > > > > >>>>>>>>>>> confirm > > > > >>>>>>>>>>>> if that's expected. > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> I think that this is caused by "-P arrow-jni" is missing in > > > > >>>>>>>>>>> 01-perform.sh: > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>> https://github.com/apache/arrow/pull/4717#issuecomment-506916189 > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> It's intentional for RC0. > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> We'll fix this after RC0: > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> https://issues.apache.org/jira/browse/ARROW-5786 > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> Thanks, > > > > >>>>>>>>>>> -- > > > > >>>>>>>>>>> kou > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> In < > > > > >>>>>>>> > > > > capwbug6wvudwu7-z8dyhq7snusagappkdzkrqof4dfnj4np...@mail.gmail.com> > > > > >>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 > > Jul > > > > >>>> 2019 > > > > >>>>>>>>>>> 06:55:52 +0530, > > > > >>>>>>>>>>> Ravindra Pindikura <ravin...@dremio.com> wrote: > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>> I tried "./dev/release/verify-release-candidate.sh source > > > > >>>> 0.14.0 > > > > >>>>>> 0" > > > > >>>>>>>> on > > > > >>>>>>>>>>> mac > > > > >>>>>>>>>>>> mojave. > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> 1. I consistently get this error with flight tests > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, > > Time > > > > >>>>>>>> elapsed: > > > > >>>>>>>>>>>> 0.04 s <<< FAILURE! - in > > > > >>>>>> org.apache.arrow.flight.TestServerOptions > > > > >>>>>>>>>>>> [ERROR] > > > > >>>> domainSocket(org.apache.arrow.flight.TestServerOptions) > > > > >>>>>>>> Time > > > > >>>>>>>>>>>> elapsed: 0.04 s <<< ERROR! > > > > >>>>>>>>>>>> java.io.IOException: Failed to bind > > > > >>>>>>>>>>>> at > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > org.apache.arrow.flight.TestServerOptions.domainSocket(TestServerOptions.java:46) > > > > >>>>>>>>>>>> Caused by: io.netty.channel.unix.Errors$NativeIoException: > > > > >>>>>> bind(..) > > > > >>>>>>>>>>> failed: > > > > >>>>>>>>>>>> Address already in use > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> Is there a workaround or gotcha for this ? > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> 2. The package doesn't seem to include gandiva > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> is that intentional ? I'm fine if it is not included, just > > > > >>>> want > > > > >>>>>> to > > > > >>>>>>>>>>> confirm > > > > >>>>>>>>>>>> if that's expected. > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> On Wed, Jul 3, 2019 at 6:37 AM Sutou Kouhei < > > > > >>>> k...@clear-code.com> > > > > >>>>>>>>>> wrote: > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>>>> I tried again (Ubuntu 18.04): > > > > >>>>>>>>>>>>>> * source verification failed in gRPC configure step: > > > > >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake > > > > >>>> files: > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> Note: Adding -Dc-ares_SOURCE=BUNDLED CMake option is > > > > >>>>>>>>>>>>> workaround. We can use bundled c-ares automatically by > > > > >>>>>>>>>>>>> requiring c-ares's CMake config: > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> https://github.com/apache/arrow/pull/4783 > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> Thanks, > > > > >>>>>>>>>>>>> -- > > > > >>>>>>>>>>>>> kou > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> In <7a82e6be-f4a5-240b-389a-4cf9cd4fb...@python.org> > > > > >>>>>>>>>>>>> "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Tue, > > 2 > > > > >>>> Jul > > > > >>>>>> 2019 > > > > >>>>>>>>>>>>> 11:36:09 +0200, > > > > >>>>>>>>>>>>> Antoine Pitrou <anto...@python.org> wrote: > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> I tried again (Ubuntu 18.04): > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> * binaries verification succeeded > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> * source verification failed in gRPC configure step: > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> CMake Error at cmake/cares.cmake:38 (find_package): > > > > >>>>>>>>>>>>>> Could not find a package configuration file provided > > by > > > > >>>>>>>> "c-ares" > > > > >>>>>>>>>>> with > > > > >>>>>>>>>>>>> any > > > > >>>>>>>>>>>>>> of the following names: > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> c-aresConfig.cmake > > > > >>>>>>>>>>>>>> c-ares-config.cmake > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> Add the installation prefix of "c-ares" to > > > > >>>>>> CMAKE_PREFIX_PATH or > > > > >>>>>>>>>> set > > > > >>>>>>>>>>>>>> "c-ares_DIR" to a directory containing one of the > > above > > > > >>>>>>>> files. If > > > > >>>>>>>>>>>>> "c-ares" > > > > >>>>>>>>>>>>>> provides a separate development package or SDK, be > > sure > > > > >>>> it > > > > >>>>>> has > > > > >>>>>>>>>> been > > > > >>>>>>>>>>>>>> installed. > > > > >>>>>>>>>>>>>> Call Stack (most recent call first): > > > > >>>>>>>>>>>>>> CMakeLists.txt:139 (include) > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> Problem is, Ubuntu's c-ares does not provide any CMake > > > > >>>> files: > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> $ dpkg -L libc-ares-dev > > > > >>>>>>>>>>>>>> /. > > > > >>>>>>>>>>>>>> /usr > > > > >>>>>>>>>>>>>> /usr/include > > > > >>>>>>>>>>>>>> /usr/include/ares.h > > > > >>>>>>>>>>>>>> /usr/include/ares_build.h > > > > >>>>>>>>>>>>>> /usr/include/ares_dns.h > > > > >>>>>>>>>>>>>> /usr/include/ares_rules.h > > > > >>>>>>>>>>>>>> /usr/include/ares_version.h > > > > >>>>>>>>>>>>>> /usr/lib > > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu > > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.a > > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig > > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/pkgconfig/libcares.pc > > > > >>>>>>>>>>>>>> /usr/share > > > > >>>>>>>>>>>>>> /usr/share/doc > > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev > > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/NEWS.gz > > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.cares > > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/README.md > > > > >>>>>>>>>>>>>> /usr/share/doc/libc-ares-dev/copyright > > > > >>>>>>>>>>>>>> /usr/share/man > > > > >>>>>>>>>>>>>> /usr/share/man/man3 > > > > >>>>>>>>>>>>>> [ snip man pages ] > > > > >>>>>>>>>>>>>> /usr/lib/x86_64-linux-gnu/libcares.so > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> Regards > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> Antoine. > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> -- > > > > >>>>>>>>>>>> Thanks and regards, > > > > >>>>>>>>>>>> Ravindra. > > > > >>>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> -- > > > > >>>>>>>>>> Thanks and regards, > > > > >>>>>>>>>> Ravindra. > > > > >>>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> -- > > > > >>>>> > > > > >>>>> Ryan Murray | Principal Consulting Engineer > > > > >>>>> > > > > >>>>> +447540852009 | rym...@dremio.com > > > > >>>>> > > > > >>>>> <https://www.dremio.com/> > > > > >>>>> Check out our GitHub <https://www.github.com/dremio>, join our > > > > >> community > > > > >>>>> site <https://community.dremio.com/> & Download Dremio > > > > >>>>> <https://www.dremio.com/download> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > >
