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> > >>>> > >>> > >> > > >
