[jira] [Created] (ARROW-5860) [Java] [Vector] Fix decimal byte setter

[Praveen Kumar Desabandu (JIRA)]

Praveen Kumar Desabandu created ARROW-5860:
--

 Summary: [Java] [Vector] Fix decimal byte setter
 Key: ARROW-5860
 URL: https://issues.apache.org/jira/browse/ARROW-5860
 Project: Apache Arrow
  Issue Type: Bug
  Components: Java
Reporter: Praveen Kumar Desabandu
Assignee: Praveen Kumar Desabandu






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[Discuss][Java] Make the semantics of lastSet consistent

[Fan Liya]

There are two lastSet member variables in the code. One is in
BaseVariableWidthVector and the other is in ListVector. In
BaseVariableWidthVector, the lastSet refers to the last index that is
actually set, while in ListVector, the lastSet refers to the next index
that will be set. So there is an inconsistency.


According to the name, lastSet should refer to the last index that is
actually set. So the semantics in ListVector should be revised. However,
the setLastSet and getLastSet methods in ListVector have been made public,
so they cannot be changed freely.


My initial idea is that: we first change the internal semantics of
ListVector, leaving the external semantics (setLastSet and getLastSet
methods) unchanged. Meanwhile, we make the setLastset & getLastSet methods
deprecated. Changing the external semantics will be performed later as a
long process.


Would you please give some comments? Do you have some other ideas?


Thank you in advance.


Liya Fan

Re: linking 3rd party cython modules against pyarrow fails since 0.14.0

[Stestagg]

1) pip install pyarrow==0.14.0
2) All the pyarrow files including, for example libarrow.so.14, but not
libarrow.so (hence the linker error)

Reproducible on Python 3.7.2 on linux mint 19.1 and debian docker:

Example dockerfile:
```
FROM debian:unstable-slim

RUN apt-get update && apt-get upgrade -y
RUN apt-get install -y python3 python3-dev
RUN apt-get install -y python3-pip

RUN python3 -m pip install --upgrade pip
RUN pip3 install Cython pyarrow
COPY setup.py /root
COPY test.pyx /root
WORKDIR /root
RUN python3 setup.py build_ext --inplace
```

Where setup.py and test.pyx are the files listed above, with an added call
to numpy.get_include().

Appending ' ==0.13.0' to the 'RUN pip3 install...' line above results in
the docker image building

Steve

On Thu, Jul 4, 2019 at 10:37 PM Antoine Pitrou  wrote:

>
> Hi,
>
> 1) How did you install PyArrow?
>
> 2) What does /usr/local/lib/python3.7/dist-packages/pyarrow contain?
>
> Regards
>
> Antoine.
>
>
> Le 04/07/2019 à 22:10, Stestagg a écrit :
> > Hi
> >
> > I've got a cython module that links against PyArrow, using the
> > 'pyarrow.get_libraries()' associated methods.
> >
> > Builds on Windows and Linux are consitently failing against 0.14, but
> > working on 0.12 to 0.13.
> >
> > Linux gives:
> > x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
> > -Wl,-z,relro -Wl,-z,relro -g -fstack-protector-strong -Wformat
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
> > build/temp.linux-x86_64-3.7/test.o
> > -L/usr/local/lib/python3.7/dist-packages/pyarrow -larrow -larrow_python
> -o
> > /home/dduser/att/arrowtest.cpython-37m-x86_64-linux-gnu.so
> > /usr/bin/ld: cannot find -larrow
> > /usr/bin/ld: cannot find -larrow_python
> > collect2: error: ld returned 1 exit status
> > error: command 'x86_64-linux-gnu-g++' failed with exit status 1
> >
> > The windows build is more funky, but I'm still investigating.
> >
> > A minimal example is:
> >
> > setup.py:
> >
> > import pyarrow
> > from Cython.Build import cythonize
> > from distutils.command.build_clib import build_clib
> > from distutils.core import setup, Extension
> >
> >
> > OPTIONS = {
> > 'sources': ["test.pyx"],
> > 'language': "c++",
> > 'include_dirs':  [pyarrow.get_include()],
> > 'libraries': pyarrow.get_libraries(),
> > 'library_dirs': pyarrow.get_library_dirs()
> > }
> >
> > setup(
> > name='arrowtest',
> > ext_modules = cythonize(Extension("arrowtest",**OPTIONS)),
> > cmdclass = {'build_clib': build_clib},
> > version="0.1",
> > )
> >
> > test.pyx:
> >
> > import pyarrow as pa
> > cimport pyarrow.lib as pa
> >
> > Thanks
> >
> > Steve
> >
>

[jira] [Created] (ARROW-5859) [Python] Support ExtentionType on conversion to numpy/pandas

[Joris Van den Bossche (JIRA)]

Joris Van den Bossche created ARROW-5859:


 Summary: [Python] Support ExtentionType on conversion to 
numpy/pandas
 Key: ARROW-5859
 URL: https://issues.apache.org/jira/browse/ARROW-5859
 Project: Apache Arrow
  Issue Type: Improvement
  Components: Python
Reporter: Joris Van den Bossche


Currently converting a Table of RecordBatch with an ExtensionType array to 
pandas gives:

{{code}}
ArrowNotImplementedError: No known equivalent Pandas block for Arrow data of 
type extension is known.
{{code}}

And similarly converting the array itself to a python object (to_pandas or 
to_pylist) gives an ArrowNotImplementedError or a "KeyError: 28"

Initial support could be to fall back to the storage type.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-5858) [Doc] Better document the Tensor classes in the prose documentation

[Joris Van den Bossche (JIRA)]

Joris Van den Bossche created ARROW-5858:


 Summary: [Doc] Better document the Tensor classes in the prose 
documentation
 Key: ARROW-5858
 URL: https://issues.apache.org/jira/browse/ARROW-5858
 Project: Apache Arrow
  Issue Type: Improvement
  Components: C++, Documentation, Python
Reporter: Joris Van den Bossche


>From a comment from [~wesmckinn] in ARROW-2714:

{quote}The Tensor classes are independent from the columnar data structures, 
though they reuse pieces of metadata, metadata serialization, memory 
management, and IPC.

The purpose of adding these to the library was to have in-memory data 
structures for handling Tensor/ndarray data and metadata that "plug in" to the 
rest of the Arrow C++ system (Plasma store, IO subsystem, memory pools, 
buffers, etc.).

Theoretically you could return a Tensor when creating a non-contiguous slice of 
an Array; in light of the above, I don't think that would be intuitive.

When we started the project, our focus was creating an open standard for 
in-memory columnar data, a hitherto unsolved problem. The project's scope has 
expanded into peripheral problems in the same domain in the meantime (with the 
mantra of creating interoperable components, a use-what-you-need development 
platform for system developers). I think this aspect of the project could be 
better documented / advertised, since the project's initial focus on the 
columnar standard has given some the mistaken impression that we are not 
interested in any work outside of that.
{quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: linking 3rd party cython modules against pyarrow fails since 0.14.0

[Antoine Pitrou]

Hi,

1) How did you install PyArrow?

2) What does /usr/local/lib/python3.7/dist-packages/pyarrow contain?

Regards

Antoine.


Le 04/07/2019 à 22:10, Stestagg a écrit :
> Hi
> 
> I've got a cython module that links against PyArrow, using the
> 'pyarrow.get_libraries()' associated methods.
> 
> Builds on Windows and Linux are consitently failing against 0.14, but
> working on 0.12 to 0.13.
> 
> Linux gives:
> x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
> -Wl,-z,relro -Wl,-z,relro -g -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
> build/temp.linux-x86_64-3.7/test.o
> -L/usr/local/lib/python3.7/dist-packages/pyarrow -larrow -larrow_python -o
> /home/dduser/att/arrowtest.cpython-37m-x86_64-linux-gnu.so
> /usr/bin/ld: cannot find -larrow
> /usr/bin/ld: cannot find -larrow_python
> collect2: error: ld returned 1 exit status
> error: command 'x86_64-linux-gnu-g++' failed with exit status 1
> 
> The windows build is more funky, but I'm still investigating.
> 
> A minimal example is:
> 
> setup.py:
> 
> import pyarrow
> from Cython.Build import cythonize
> from distutils.command.build_clib import build_clib
> from distutils.core import setup, Extension
> 
> 
> OPTIONS = {
> 'sources': ["test.pyx"],
> 'language': "c++",
> 'include_dirs':  [pyarrow.get_include()],
> 'libraries': pyarrow.get_libraries(),
> 'library_dirs': pyarrow.get_library_dirs()
> }
> 
> setup(
> name='arrowtest',
> ext_modules = cythonize(Extension("arrowtest",**OPTIONS)),
> cmdclass = {'build_clib': build_clib},
> version="0.1",
> )
> 
> test.pyx:
> 
> import pyarrow as pa
> cimport pyarrow.lib as pa
> 
> Thanks
> 
> Steve
> 

[jira] [Created] (ARROW-5857) [Python] converting multidimensional numpy arrays to nested list type

[Joris Van den Bossche (JIRA)]

Joris Van den Bossche created ARROW-5857:


 Summary: [Python] converting multidimensional numpy arrays to 
nested list type
 Key: ARROW-5857
 URL: https://issues.apache.org/jira/browse/ARROW-5857
 Project: Apache Arrow
  Issue Type: Improvement
  Components: Python
Reporter: Joris Van den Bossche


Currently we only support 1-dimensional numpy arrays:

{code:python}
In [28]: pa.array([np.array([[1, 2], [3, 4]])], 
type=pa.list_(pa.list_(pa.int64( 
...
ArrowInvalid: Can only convert 1-dimensional array values
{code}

So to create a nested list array, you can do that with lists of lists or object 
numpy arrays with arrays as elements. We could expand this support to 
multi-dimensional numpy arrays.

I am not sure we should do inference by default for this case, but at least 
when specifying a nested ListType, this would be nice. 

It can be an alternative way to have some support for tensors, next to an 
ExtensionType (ARROW-1614 / ARROW-5819)

Related discussions: 
https://lists.apache.org/thread.html/9b142c1709aa37dc35f1ce8db4e1ced94fcc4cdd96cc72b5772b373b@%3Cdev.arrow.apache.org%3E,
 https://github.com/apache/arrow/issues/4802



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-5856) linking 3rd party cython modules against pyarrow fails since 0.14.0

[Steve Stagg (JIRA)]

Steve Stagg created ARROW-5856:
--

 Summary: linking 3rd party cython modules against pyarrow fails 
since 0.14.0
 Key: ARROW-5856
 URL: https://issues.apache.org/jira/browse/ARROW-5856
 Project: Apache Arrow
  Issue Type: Bug
  Components: Python
Affects Versions: 0.14.0
Reporter: Steve Stagg
 Attachments: setup.py, test.pyx

Compiling cython modules that link to the pyarrow library, using the 
recommended approach for getting the appropriate include and link flags has 
stopped working for PyArrow 0.14.0.

 

A minimal test case is included in the attachments that demonstrates the 
problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

linking 3rd party cython modules against pyarrow fails since 0.14.0

[Stestagg]

Hi

I've got a cython module that links against PyArrow, using the
'pyarrow.get_libraries()' associated methods.

Builds on Windows and Linux are consitently failing against 0.14, but
working on 0.12 to 0.13.

Linux gives:
x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
-Wl,-z,relro -Wl,-z,relro -g -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
build/temp.linux-x86_64-3.7/test.o
-L/usr/local/lib/python3.7/dist-packages/pyarrow -larrow -larrow_python -o
/home/dduser/att/arrowtest.cpython-37m-x86_64-linux-gnu.so
/usr/bin/ld: cannot find -larrow
/usr/bin/ld: cannot find -larrow_python
collect2: error: ld returned 1 exit status
error: command 'x86_64-linux-gnu-g++' failed with exit status 1

The windows build is more funky, but I'm still investigating.

A minimal example is:

setup.py:

import pyarrow
from Cython.Build import cythonize
from distutils.command.build_clib import build_clib
from distutils.core import setup, Extension


OPTIONS = {
'sources': ["test.pyx"],
'language': "c++",
'include_dirs':  [pyarrow.get_include()],
'libraries': pyarrow.get_libraries(),
'library_dirs': pyarrow.get_library_dirs()
}

setup(
name='arrowtest',
ext_modules = cythonize(Extension("arrowtest",**OPTIONS)),
cmdclass = {'build_clib': build_clib},
version="0.1",
)

test.pyx:

import pyarrow as pa
cimport pyarrow.lib as pa

Thanks

Steve

[jira] [Created] (ARROW-5855) [Python] Add support for Duration type

[Joris Van den Bossche (JIRA)]

Joris Van den Bossche created ARROW-5855:


 Summary: [Python] Add support for Duration type
 Key: ARROW-5855
 URL: https://issues.apache.org/jira/browse/ARROW-5855
 Project: Apache Arrow
  Issue Type: Improvement
  Components: Python
Reporter: Joris Van den Bossche
 Fix For: 1.0.0


Add support for the Duration type (added in C++: ARROW-835, ARROW-5261)

- add DurationType and DurationArray wrappers
- add inference support for datetime.timedelta / np.timedelta64



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-5854) [Python] Expose compare kernels on Array class

[Joris Van den Bossche (JIRA)]

Joris Van den Bossche created ARROW-5854:


 Summary: [Python] Expose compare kernels on Array class
 Key: ARROW-5854
 URL: https://issues.apache.org/jira/browse/ARROW-5854
 Project: Apache Arrow
  Issue Type: Improvement
  Components: Python
Reporter: Joris Van den Bossche


Expose the compare kernel for comparing with scalar or array 
(https://issues.apache.org/jira/browse/ARROW-3087, 
https://issues.apache.org/jira/browse/ARROW-4990) on the python Array class.

This can implement the {{\_\_eq\_\_}} et al dunder methods on the Array class.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-5853) [Python] Expose boolean filter kernel on Array

[Joris Van den Bossche (JIRA)]

Joris Van den Bossche created ARROW-5853:


 Summary: [Python] Expose boolean filter kernel on Array
 Key: ARROW-5853
 URL: https://issues.apache.org/jira/browse/ARROW-5853
 Project: Apache Arrow
  Issue Type: Improvement
  Components: Python
Reporter: Joris Van den Bossche


Expose the filter kernel (https://issues.apache.org/jira/browse/ARROW-1558) on 
the python Array class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Flight authentication interoperability

[Ryan Murray]

Hey David,

I was actually testing test_flight.test_http_basic_auth(). But I think the
same applies. The Java default implementation expects a handshake. More to
the point it expects a BasicAuth protobuf which I believe is not exposed at
all in python. Always returning true in
BasicServerAuthHandler.authenticate() allows for the test implementations
of Java and Python authentication to speak to each other.

Thanks for the below link, that really clarified things for me. I would add
to the list that we should normalise the use of BasicAuth protobuf message
between java and cpp.

Apologies for the urgency yesterday, I am glad it was sorted and more my
fault than Arrow's.

Best,
Ryan


On Thu, Jul 4, 2019 at 11:29 AM David Li  wrote:

> Hmm, interesting. I assume you mean test_flight.test_token_auth() as
> the client? The tests weren't written to be explicitly compatible, but
> there's no reason you should get an indefinite stall.
>
> We don't use Handshake/ServerAuthHandler#authenticate, so that would
> explain why we don't see issues. I commented on this in the initial
> implementation:
> https://github.com/apache/arrow/pull/4125#discussion_r273935691
>
> > there is not a 1-1 mapping between connected clients and connected
> peers, and so you can
> > only know the identity of the peer at the moment it makes a call. Just
> doing a handshake
> > (Authenticate) isn't enough to identify who is on the other end of a
> particular connection.
>
> the reason being that a layer 7 load balancer (e.g. Envoy) means one
> gRPC connection can represent multiple clients. Conversely,
> client-side load balancing (built into gRPC) means one client-side
> "connection" can actually represent multiple servers. Of course, you
> have to consciously deploy in this manner, so Handshake is still
> useful if you know you won't ever need these features.
>
> As I see it, this means there's a few things to work on:
> - Flight RPC feature compatibility needs to be tested, not just format
> compatibility.
> - We should start thinking about async APIs and/or timeouts in any
> sort of API that makes a network call (there's already a JIRA:
> https://issues.apache.org/jira/browse/ARROW-1009), since "never
> returns" is a terrible failure mode
>
> Best,
> David
>
> On 7/4/19, Ryan Murray  wrote:
> > Hey David,
> >
> > I am curious to see what you are doing different from me. I am running
> the
> > Java ExampleFlightServer.java against the python auth flight tests and
> they
> > are not passing. The particular issue is that incoming.next() never
> returns
> > in BasicServerAuthHandler.java:56
> >
> > It doesn't appear to be anything wrong w/ the auth piece specifically
> > rather the server appears to not be getting the auth info to verify. I am
> > still investigating my issue but I am glad that someone else has gotten
> > this to work.
> >
> > Best,
> > Ryan
> >
> > On Thu, Jul 4, 2019 at 9:13 AM Antoine Pitrou 
> wrote:
> >
> >>
> >> It may be worth opening a JIRA for the flaky tests if not already done.
> >>
> >> Regards
> >>
> >> Antoine.
> >>
> >>
> >> Le 04/07/2019 à 18:11, David Li a écrit :
> >> > I'm also curious as to what the issue was, as we've been doing
> >> > Python-client-Java-server auth with development builds without
> >> > trouble.
> >> >
> >> > Regardless - this does point out a need for more cross-language Flight
> >> > testing (perhaps a Flight-specific integration suite?), and to get
> >> > existing tests running more consistently in CI (Flight/Java in
> >> > particular has a lot of flaky tests, though the auth tests are enabled
> >> > in Travis).
> >> >
> >> > Best,
> >> > David
> >> >
> >> > On 7/4/19, Jacques Nadeau  wrote:
> >> >> Which is exactly why I was withholding a vote until there was more
> >> >> information.
> >> >>
> >> >> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou 
> >> wrote:
> >> >>
> >> >>> On Thu, 4 Jul 2019 09:04:34 -0500
> >> >>> Wes McKinney  wrote:
> >> 
> >>  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.
> >> >>>
> >> >>> OTOH, it's a bit unlikely.  Flight authentication is implemented is:
> >> >>> - the Arrow codebase simply passes opaque tokens around
> >> >>> - interpretation of tokens is handled by application code
> >> >>> - marshalling of tokens is handled by Protocol Buffers
> >> >>>
> >> >>> So unless something silly is going on (such as "passing an empty
> >> >>> string
> >> >>> instead of the actual token") there's not much potential for
> >> >>> auth interoperability issues in the core Flight codebase.
> >> >>>
> >> >>> Regards
> >> >>>
> >> >>> Antoine.
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >>
> >
> >
> > --
> >
> > Ryan Murray  | Principal Consulting Engineer
> >
> > +447540852009 | rym...@dremio.com
> >
> > 
> > Check 

Re: Flight authentication interoperability

[David Li]

Hmm, interesting. I assume you mean test_flight.test_token_auth() as
the client? The tests weren't written to be explicitly compatible, but
there's no reason you should get an indefinite stall.

We don't use Handshake/ServerAuthHandler#authenticate, so that would
explain why we don't see issues. I commented on this in the initial
implementation:
https://github.com/apache/arrow/pull/4125#discussion_r273935691

> there is not a 1-1 mapping between connected clients and connected peers, and 
> so you can
> only know the identity of the peer at the moment it makes a call. Just doing 
> a handshake
> (Authenticate) isn't enough to identify who is on the other end of a 
> particular connection.

the reason being that a layer 7 load balancer (e.g. Envoy) means one
gRPC connection can represent multiple clients. Conversely,
client-side load balancing (built into gRPC) means one client-side
"connection" can actually represent multiple servers. Of course, you
have to consciously deploy in this manner, so Handshake is still
useful if you know you won't ever need these features.

As I see it, this means there's a few things to work on:
- Flight RPC feature compatibility needs to be tested, not just format
compatibility.
- We should start thinking about async APIs and/or timeouts in any
sort of API that makes a network call (there's already a JIRA:
https://issues.apache.org/jira/browse/ARROW-1009), since "never
returns" is a terrible failure mode

Best,
David

On 7/4/19, Ryan Murray  wrote:
> Hey David,
>
> I am curious to see what you are doing different from me. I am running the
> Java ExampleFlightServer.java against the python auth flight tests and they
> are not passing. The particular issue is that incoming.next() never returns
> in BasicServerAuthHandler.java:56
>
> It doesn't appear to be anything wrong w/ the auth piece specifically
> rather the server appears to not be getting the auth info to verify. I am
> still investigating my issue but I am glad that someone else has gotten
> this to work.
>
> Best,
> Ryan
>
> On Thu, Jul 4, 2019 at 9:13 AM Antoine Pitrou  wrote:
>
>>
>> It may be worth opening a JIRA for the flaky tests if not already done.
>>
>> Regards
>>
>> Antoine.
>>
>>
>> Le 04/07/2019 à 18:11, David Li a écrit :
>> > I'm also curious as to what the issue was, as we've been doing
>> > Python-client-Java-server auth with development builds without
>> > trouble.
>> >
>> > Regardless - this does point out a need for more cross-language Flight
>> > testing (perhaps a Flight-specific integration suite?), and to get
>> > existing tests running more consistently in CI (Flight/Java in
>> > particular has a lot of flaky tests, though the auth tests are enabled
>> > in Travis).
>> >
>> > Best,
>> > David
>> >
>> > On 7/4/19, Jacques Nadeau  wrote:
>> >> Which is exactly why I was withholding a vote until there was more
>> >> information.
>> >>
>> >> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou 
>> wrote:
>> >>
>> >>> On Thu, 4 Jul 2019 09:04:34 -0500
>> >>> Wes McKinney  wrote:
>> 
>>  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.
>> >>>
>> >>> OTOH, it's a bit unlikely.  Flight authentication is implemented is:
>> >>> - the Arrow codebase simply passes opaque tokens around
>> >>> - interpretation of tokens is handled by application code
>> >>> - marshalling of tokens is handled by Protocol Buffers
>> >>>
>> >>> So unless something silly is going on (such as "passing an empty
>> >>> string
>> >>> instead of the actual token") there's not much potential for
>> >>> auth interoperability issues in the core Flight codebase.
>> >>>
>> >>> Regards
>> >>>
>> >>> Antoine.
>> >>>
>> >>>
>> >>>
>> >>
>>
>
>
> --
>
> Ryan Murray  | Principal Consulting Engineer
>
> +447540852009 | rym...@dremio.com
>
> 
> Check out our GitHub , join our community
> site  & Download Dremio
> 
>

[CI] Ursabot Java builders

[Krisztián Szűcs]

Hi,

I've added simple Java builders for JDK 8 and 11.
The required change was quite small [1], but a build
takes a bit more than 2 minutes [2].
Adding Go and Rust builders should be similarly easy.

Regard, Krisztian

[1]:
https://github.com/ursa-labs/ursabot/commit/476a8b07fd81f6d7664dc5e115e079d014e54436
[2]: https://ci.ursalabs.org/#/builders/89/builds/2

Re: Flight authentication interoperability

[Ryan Murray]

Hey David,

I am curious to see what you are doing different from me. I am running the
Java ExampleFlightServer.java against the python auth flight tests and they
are not passing. The particular issue is that incoming.next() never returns
in BasicServerAuthHandler.java:56

It doesn't appear to be anything wrong w/ the auth piece specifically
rather the server appears to not be getting the auth info to verify. I am
still investigating my issue but I am glad that someone else has gotten
this to work.

Best,
Ryan

On Thu, Jul 4, 2019 at 9:13 AM Antoine Pitrou  wrote:

>
> It may be worth opening a JIRA for the flaky tests if not already done.
>
> Regards
>
> Antoine.
>
>
> Le 04/07/2019 à 18:11, David Li a écrit :
> > I'm also curious as to what the issue was, as we've been doing
> > Python-client-Java-server auth with development builds without
> > trouble.
> >
> > Regardless - this does point out a need for more cross-language Flight
> > testing (perhaps a Flight-specific integration suite?), and to get
> > existing tests running more consistently in CI (Flight/Java in
> > particular has a lot of flaky tests, though the auth tests are enabled
> > in Travis).
> >
> > Best,
> > David
> >
> > On 7/4/19, Jacques Nadeau  wrote:
> >> Which is exactly why I was withholding a vote until there was more
> >> information.
> >>
> >> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou 
> wrote:
> >>
> >>> On Thu, 4 Jul 2019 09:04:34 -0500
> >>> Wes McKinney  wrote:
> 
>  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.
> >>>
> >>> OTOH, it's a bit unlikely.  Flight authentication is implemented is:
> >>> - the Arrow codebase simply passes opaque tokens around
> >>> - interpretation of tokens is handled by application code
> >>> - marshalling of tokens is handled by Protocol Buffers
> >>>
> >>> So unless something silly is going on (such as "passing an empty string
> >>> instead of the actual token") there's not much potential for
> >>> auth interoperability issues in the core Flight codebase.
> >>>
> >>> Regards
> >>>
> >>> Antoine.
> >>>
> >>>
> >>>
> >>
>


-- 

Ryan Murray  | Principal Consulting Engineer

+447540852009 | rym...@dremio.com


Check out our GitHub , join our community
site  & Download Dremio

[jira] [Created] (ARROW-5852) [Rust] [DataFusion] Compilation error with Rust 1.37.0-nightly

[Andy Grove (JIRA)]

Andy Grove created ARROW-5852:
-

 Summary: [Rust] [DataFusion] Compilation error with Rust 
1.37.0-nightly
 Key: ARROW-5852
 URL: https://issues.apache.org/jira/browse/ARROW-5852
 Project: Apache Arrow
  Issue Type: New Feature
  Components: Rust, Rust - DataFusion
Affects Versions: 0.14.0
Reporter: Andy Grove
Assignee: Andy Grove
 Fix For: 0.14.0


{code:java}
error[E0283]: type annotations required: cannot resolve `std::string::String: 
std::convert::AsRef<_>`
   --> 
/home/andy/.cargo/registry/src/github.com-1ecc6299db9ec823/rustyline-3.0.0/src/lib.rs:655:43
    |
655 | editor.add_history_entry(line.as_ref());
    |   ^^

{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Flight authentication interoperability

[Antoine Pitrou]

It may be worth opening a JIRA for the flaky tests if not already done.

Regards

Antoine.


Le 04/07/2019 à 18:11, David Li a écrit :
> I'm also curious as to what the issue was, as we've been doing
> Python-client-Java-server auth with development builds without
> trouble.
> 
> Regardless - this does point out a need for more cross-language Flight
> testing (perhaps a Flight-specific integration suite?), and to get
> existing tests running more consistently in CI (Flight/Java in
> particular has a lot of flaky tests, though the auth tests are enabled
> in Travis).
> 
> Best,
> David
> 
> On 7/4/19, Jacques Nadeau  wrote:
>> Which is exactly why I was withholding a vote until there was more
>> information.
>>
>> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou  wrote:
>>
>>> On Thu, 4 Jul 2019 09:04:34 -0500
>>> Wes McKinney  wrote:

 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.
>>>
>>> OTOH, it's a bit unlikely.  Flight authentication is implemented is:
>>> - the Arrow codebase simply passes opaque tokens around
>>> - interpretation of tokens is handled by application code
>>> - marshalling of tokens is handled by Protocol Buffers
>>>
>>> So unless something silly is going on (such as "passing an empty string
>>> instead of the actual token") there's not much potential for
>>> auth interoperability issues in the core Flight codebase.
>>>
>>> Regards
>>>
>>> Antoine.
>>>
>>>
>>>
>>

Re: Flight authentication interoperability

[David Li]

I'm also curious as to what the issue was, as we've been doing
Python-client-Java-server auth with development builds without
trouble.

Regardless - this does point out a need for more cross-language Flight
testing (perhaps a Flight-specific integration suite?), and to get
existing tests running more consistently in CI (Flight/Java in
particular has a lot of flaky tests, though the auth tests are enabled
in Travis).

Best,
David

On 7/4/19, Jacques Nadeau  wrote:
> Which is exactly why I was withholding a vote until there was more
> information.
>
> On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou  wrote:
>
>> On Thu, 4 Jul 2019 09:04:34 -0500
>> Wes McKinney  wrote:
>> >
>> > 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.
>>
>> OTOH, it's a bit unlikely.  Flight authentication is implemented is:
>> - the Arrow codebase simply passes opaque tokens around
>> - interpretation of tokens is handled by application code
>> - marshalling of tokens is handled by Protocol Buffers
>>
>> So unless something silly is going on (such as "passing an empty string
>> instead of the actual token") there's not much potential for
>> auth interoperability issues in the core Flight codebase.
>>
>> Regards
>>
>> Antoine.
>>
>>
>>
>

[jira] [Created] (ARROW-5851) [C++] Compilation of reference benchmarks fails

[Antoine Pitrou (JIRA)]

Antoine Pitrou created ARROW-5851:
-

 Summary: [C++] Compilation of reference benchmarks fails
 Key: ARROW-5851
 URL: https://issues.apache.org/jira/browse/ARROW-5851
 Project: Apache Arrow
  Issue Type: Bug
  Components: C++
Affects Versions: 0.14.0
Reporter: Antoine Pitrou
Assignee: Antoine Pitrou


{code}
../src/arrow/util/compression-benchmark.cc: In function 'void 
arrow::util::StreamingDecompression(arrow::Compression::type, const 
std::vector&, benchmark::State&)':
../src/arrow/util/compression-benchmark.cc:172:5: error: 'ARROW_CHECK' was not 
declared in this scope
 ARROW_CHECK(decompressed_size == static_cast(data.size()));
 ^~~
../src/arrow/util/compression-benchmark.cc:172:5: note: suggested alternative: 
'ARROW_CONCAT'
 ARROW_CHECK(decompressed_size == static_cast(data.size()));
 ^~~
 ARROW_CONCAT
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Release verification process

[Wes McKinney]

hi Neal,

On Thu, Jul 4, 2019 at 9:31 AM Neal Richardson
 wrote:
>
> Hi all,
> [Splitting off from the [VOTE] discussion thread]
>
> I wonder if there are things we can do to make for a smoother release next
> time. This was the first release I participated in with the Arrow project,
> and there were some aspects that were surprising to me. It seemed odd that
> "release verification" involved manually running a bunch of tests that
> weren't expected to pass, and then reporting that they didn't pass, and
> then forging ahead anyway.
>

Verification means different things to different people. The purpose
of the verification script is to try to build as many components of
the project as possible in a standalone way, using system environment
and dependencies in some cases. It helps turn up issues that do not
appear in the controlled CI environment.

Others will verify the release by testing their third party
applications using the software as a dependency.

> Perhaps we could, at the beginning of the release process and before making
> the first RC, make clear what is expected in order to verify it, and also
> state what is not required or expected. And we shouldn't spend time running
> tests that we don't care whether they fail or not. That way, we can have
> the discussion of what a successful release looks like before there's an RC
> on the table and a sense of urgency to ship it, and then it will be clear
> to everyone that the standards have been met when we run the tests.
>

I understand where you're coming from, but the release verification
process is intended to collect idiosyncratic information from people
attempting to use the software in different ways. I doubt that we
could write down satisfactory standards a priori or a cookie cutter
verification process that can be guaranteed to work for everyone. It's
been suggested in the past to convert the release verification to a
Dockerfile, but my view is that defeats the purpose of the script.

Note that our CI and Docker integration tests already provide a
certain level of security -- so we would hope to not have an RC unless
CI and docker-* tests are all passing (which they were here).

> Regardless of how we might want to improve the process for next time, I
> appreciate all of the hard work that Kou (especially) and others put in to
> making the release happen. Releasing a project of this size clearly takes a
> lot of dedication and effort.
>
> Neal
>
>
> On Thu, Jul 4, 2019 at 7:05 AM Wes McKinney  wrote:
>
> > hi Jacques,
> >
> > I agree that we should allow ample time for discussions around issues
> > raised by people validating the release.
> >
> > 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.
> >
> > 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.
> >
> > - Wes
> >
> >
> > On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau  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  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 

Re: [VOTE] Release Apache Arrow 0.14.0 - RC0

[Wes McKinney]

On Thu, Jul 4, 2019 at 9:25 AM Jacques Nadeau  wrote:
>
> On Thu, Jul 4, 2019, 7:05 AM Wes McKinney  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  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  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 

[jira] [Created] (ARROW-5850) [CI][R] R appveyor job is broken after release

[Neal Richardson (JIRA)]

Neal Richardson created ARROW-5850:
--

 Summary: [CI][R] R appveyor job is broken after release
 Key: ARROW-5850
 URL: https://issues.apache.org/jira/browse/ARROW-5850
 Project: Apache Arrow
  Issue Type: Bug
  Components: Continuous Integration, R
Reporter: Neal Richardson
Assignee: Neal Richardson


I forgot to add ci/PKGBUILD to the release script that bumps all of the 
versions, so the pkgver it has is out of sync with what is in r/DESCRIPTION 
after the release. 

To fix, either update the pkgver in ci/PKGBUILD and add code to the release 
script and tests to bump its version, or remove the pkgver field entirely and 
just read it from r/DESCRIPTION in the pkgver() function, if makepkg allows 
that. Unclear if one solution is clearly better than the other.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Release standards

[Jacques Nadeau]

You don't hold the release for the issue, you hold it for consensus. This
allows other people to come to the same conclusion (or not). That's why
it's called community over code.

On Thu, Jul 4, 2019, 7:33 AM Antoine Pitrou  wrote:

> On Thu, 4 Jul 2019 07:25:05 -0700
> Jacques Nadeau  wrote:
> >
> > > 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.
>
> Well... The fact that the problem isn't reproduced or confirmed as a
> Arrow bug (rather than a bug in application code, which is IMHO more
> likely given the way Flight authentication works) makes it a bit
> difficult to hold the release for it.
>
> Regards
>
> Antoine.
>
>
>

Re: Flight authentication interoperability

[Jacques Nadeau]

Which is exactly why I was withholding a vote until there was more
information.

On Thu, Jul 4, 2019, 7:25 AM Antoine Pitrou  wrote:

> On Thu, 4 Jul 2019 09:04:34 -0500
> Wes McKinney  wrote:
> >
> > 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.
>
> OTOH, it's a bit unlikely.  Flight authentication is implemented is:
> - the Arrow codebase simply passes opaque tokens around
> - interpretation of tokens is handled by application code
> - marshalling of tokens is handled by Protocol Buffers
>
> So unless something silly is going on (such as "passing an empty string
> instead of the actual token") there's not much potential for
> auth interoperability issues in the core Flight codebase.
>
> Regards
>
> Antoine.
>
>
>

Re: Release standards

[Antoine Pitrou]

On Thu, 4 Jul 2019 07:25:05 -0700
Jacques Nadeau  wrote:
> 
> > 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.

Well... The fact that the problem isn't reproduced or confirmed as a
Arrow bug (rather than a bug in application code, which is IMHO more
likely given the way Flight authentication works) makes it a bit
difficult to hold the release for it.

Regards

Antoine.

Release verification process

[Neal Richardson]

Hi all,
[Splitting off from the [VOTE] discussion thread]

I wonder if there are things we can do to make for a smoother release next
time. This was the first release I participated in with the Arrow project,
and there were some aspects that were surprising to me. It seemed odd that
"release verification" involved manually running a bunch of tests that
weren't expected to pass, and then reporting that they didn't pass, and
then forging ahead anyway.

Perhaps we could, at the beginning of the release process and before making
the first RC, make clear what is expected in order to verify it, and also
state what is not required or expected. And we shouldn't spend time running
tests that we don't care whether they fail or not. That way, we can have
the discussion of what a successful release looks like before there's an RC
on the table and a sense of urgency to ship it, and then it will be clear
to everyone that the standards have been met when we run the tests.

Regardless of how we might want to improve the process for next time, I
appreciate all of the hard work that Kou (especially) and others put in to
making the release happen. Releasing a project of this size clearly takes a
lot of dedication and effort.

Neal


On Thu, Jul 4, 2019 at 7:05 AM Wes McKinney  wrote:

> hi Jacques,
>
> I agree that we should allow ample time for discussions around issues
> raised by people validating the release.
>
> 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.
>
> 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.
>
> - Wes
>
>
> On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau  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  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 
> 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. 

Re: [VOTE] Release Apache Arrow 0.14.0 - RC0

[Jacques Nadeau]

On Thu, Jul 4, 2019, 7:05 AM Wes McKinney  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'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.

>
>
> On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau  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  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 
> 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 
> wrote:
> > > >>>
> > >  Hi,
> 

Re: Flight authentication interoperability

[Antoine Pitrou]

On Thu, 4 Jul 2019 09:04:34 -0500
Wes McKinney  wrote:
> 
> 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.

OTOH, it's a bit unlikely.  Flight authentication is implemented is:
- the Arrow codebase simply passes opaque tokens around
- interpretation of tokens is handled by application code
- marshalling of tokens is handled by Protocol Buffers

So unless something silly is going on (such as "passing an empty string
instead of the actual token") there's not much potential for
auth interoperability issues in the core Flight codebase.

Regards

Antoine.

Re: [VOTE] Release Apache Arrow 0.14.0 - RC0

[Wes McKinney]

hi Jacques,

I agree that we should allow ample time for discussions around issues
raised by people validating the release.

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.

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.

- Wes


On Thu, Jul 4, 2019 at 8:50 AM Jacques Nadeau  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  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  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  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  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 
> > >> wrote:
> > >
> > >> Thanks for confirming it!
> > >>
> > >> This will be solved by the pull request.
> > >>
> > >> In <
> > >> 

Re: [VOTE] Release Apache Arrow 0.14.0 - RC0

[Jacques Nadeau]

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  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  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  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  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 
> >> 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  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 
>  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  wrote:
> 
> > On MacOS Mojave. Verified Rust and Go with
>  

Re: [VOTE] Release Apache Arrow 0.14.0 - RC0

[Antoine Pitrou]

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  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  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 
   "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
 17:18:15 -0700,
   Ryan Murray  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 
>> 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  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 
 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  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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:

Re: [RESULT][VOTE] Release Apache Arrow 0.14.0 - RC0

[Neal Richardson]

I'll get the ball rolling on the R packages.

Neal

On Thu, Jul 4, 2019 at 12:46 AM Sutou Kouhei  wrote:

> Hi,
>
> I need your help!
> Could Rust developers see "Failed:" section?
> Could someone take over tasks in "Need helped:" section?
>
> Failed:
>
>   * Updating Rust packages
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingRustpackages
>
> * We need the following patch:
>
> 
> diff --git a/dev/release/post-07-rust.sh b/dev/release/post-07-rust.sh
> index a2f6e2988..c632fa793 100755
> --- a/dev/release/post-07-rust.sh
> +++ b/dev/release/post-07-rust.sh
> @@ -53,6 +53,12 @@ curl \
>  rm -rf ${archive_name}
>  tar xf ${tar_gz}
>  modules=()
> +  sed \
> +-i \
> +-E \
> +-e 's/^arrow = "([^"]*)"/arrow = { version = "\1", path = "..\/arrow"
> }/g' \
> +-e 's/^parquet = "([^"]*)"/parquet = { version = "\1", path =
> "..\/parquet" }/g' \
> +${archive_name}/rust/*/Cargo.toml
>  for cargo_toml in ${archive_name}/rust/*/Cargo.toml; do
>module_dir=$(dirname ${cargo_toml})
>pushd ${module_dir}
> 
>
> * "INSTALL_RUST=yes dev/release/post-07-rust.sh 0.14.0"
>   is failed with the above patch:
>
> 
>Packaging arrow v0.14.0
> (/home/kou/work/cpp/arrow.kou/apache-arrow-0.14.0/rust/arrow)
>Verifying arrow v0.14.0
> (/home/kou/work/cpp/arrow.kou/apache-arrow-0.14.0/rust/arrow)
> error: failed to verify package tarball
>
> Caused by:
>   failed to parse manifest at
> `/home/kou/work/cpp/arrow.kou/apache-arrow-0.14.0/rust/target/package/arrow-0.14.0/Cargo.toml`
>
> Caused by:
>   can't find `array_from_vec` bench, specify bench.path
> 
>
> * How to solve this?
>
> Done:
>
>   * Rebasing the master branch on local release branch
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Rebasingthemasterbranchonlocalreleasebranch
>
>   * Marking the released version as "RELEASED" on JIRA
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Markingthereleasedversionas%22RELEASED%22onJIRA
>
>   * Starting the new version on JIRA
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-StartingthenewversiononJIRA
>
>   * Partially: Updating the Arrow website
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingtheArrowwebsite
>
> * Release note has been added.
> * No blog post.
> * Not upload to website yet.
>
>   * Uploading source release artifacts to SVN
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UploadingsourcereleaseartifactstoSVN
>
>   * Uploading binary release artifacts to Bintray
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UploadingbinaryreleaseartifactstoBintray
>
>   * Partially: Announcing release
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Announcingrelease
>
> * Added release date.
> * Not send release announce to announce@ and dev@ yet.
>
>   * Partially: Updating C++ and Python packages
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingC++andPythonpackages
>
> * Uploaded to PyPI.
>   * Wrote upload shell script but not create pull request yet.
> * Not update conda packages yet
>
>   * Updating Java Maven artifacts in Maven central
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingJavaMavenartifactsinMavencentral
>
>   * Updating Ruby packages
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingRubypackages
>
>   * Updating JavaScript packages
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingJavaScriptpackages
>
>   * Updating .NET NuGet packages
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Updating.NETNuGetpackages
>
>   * Removing source artifacts for RC
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-RemovingsourceartifactsforRC
>
> Need help:
>
>   * All pull requests need to rebase on master by
> "Rebasing the master branch on local release branch"
>
>   * Blog post
>
>   * Update website
>
>   * Announcing release to announce@ and dev@
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Announcingrelease
>
>   * Updating website with new API documentation
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingwebsitewithnewAPIdocumentation
>
>   * Updating conda packages
>
> 

Re: [VOTE] Release Apache Arrow 0.14.0 - RC0

[Jacques Nadeau]

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  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  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 
> >>   "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >> 17:18:15 -0700,
> >>   Ryan Murray  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 
> 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  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 
> >> 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  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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> >>>
> >>
> 
> >>
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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'
> 

Re: [VOTE] Release Apache Arrow 0.14.0 - RC0

[Krisztián Szűcs]

The issue report was hardly reproducible, and it wasn't captured by any
of the automatized test suites. Until we don't have automatized tests for
a feature I wouldn't consider it stable.
If this is something we should have blocked the release on, then we can
still draft a minor release after fixing it.

- Krisztian

On Thu, Jul 4, 2019 at 2:47 PM Jacques Nadeau  wrote:

> 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  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 
> >   "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> > 17:18:15 -0700,
> >   Ryan Murray  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 
> 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  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 
> > 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  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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> > >> >> >
> > >> >>
> > >>
> >
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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
> > >> >> > 

Re: [VOTE] Release Apache Arrow 0.14.0 - RC0

[Antoine Pitrou]

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  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 
>>   "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
>> 17:18:15 -0700,
>>   Ryan Murray  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  wrote:
>>>
 Thanks for confirming it!

 This will be solved by the pull request.

 In 
   "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
 13:53:19 -0700,
   Chao Sun  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 
>> 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  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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
>>>
>>

>> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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

Re: [VOTE] Release Apache Arrow 0.14.0 - RC0

[Jacques Nadeau]

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  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 
>   "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> 17:18:15 -0700,
>   Ryan Murray  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  wrote:
> >
> >> Thanks for confirming it!
> >>
> >> This will be solved by the pull request.
> >>
> >> In 
> >>   "Re: [VOTE] Release Apache Arrow 0.14.0 - RC0" on Wed, 3 Jul 2019
> >> 13:53:19 -0700,
> >>   Chao Sun  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 
> 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  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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.yYmSAqR5/apache-arrow-0.14.0/cpp/build/orc_ep-prefix/src/orc_ep/c++/src/io/OutputStream.cc:20:
> >> >> >
> >> >>
> >>
> ^[[1m/var/folders/z3/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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/ptkgr4kn4pv9v8g7s1fnr5mmgn/T/arrow-0.14.0.X.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 
> >> wrote:
> >> >> >>
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > Thanks for verifying this RC!
> >> 

[jira] [Created] (ARROW-5849) Compiler warnings on mingw-w64

[Jeroen (JIRA)]

Jeroen created ARROW-5849:
-

 Summary: Compiler warnings on mingw-w64
 Key: ARROW-5849
 URL: https://issues.apache.org/jira/browse/ARROW-5849
 Project: Apache Arrow
  Issue Type: Bug
  Components: C++
Affects Versions: 0.14.0
Reporter: Jeroen


In mingw64 we see the following warnings:

{code}
[ 54%] Building CXX object 
src/arrow/CMakeFiles/arrow_static.dir/util/io-util.cc.obj
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/util/decimal.cc:
 In static member function 'static arrow::Status 
arrow::Decimal128::FromString(const string_view&, arrow::Decimal128*, int32_t*, 
int32_t*)':
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/util/decimal.cc:313:35:
 warning: 'dec.arrow::{anonymous}::DecimalComponents::exponent' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   *scale = -adjusted_exponent + len - 1;
~~~^~~~
{code} 

{code}
[ 56%] Building CXX object 
src/arrow/CMakeFiles/arrow_static.dir/util/string_builder.cc.obj
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/util/io-util.cc:
 In static member function 'static arrow::Status 
arrow::internal::TemporaryDir::Make(const string&, 
std::unique_ptr*)':
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/util/io-util.cc:897:3:
 warning: 'created' may be used uninitialized in this function 
[-Wmaybe-uninitialized]
   if (!created) {
   ^~
{code}

And on mingw32 we also see these:

{code}
[ 56%] Building CXX object 
src/arrow/CMakeFiles/arrow_static.dir/util/string_builder.cc.obj
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/util/io-util.cc:
 In static member function 'static arrow::Status 
arrow::internal::TemporaryDir::Make(const string&, 
std::unique_ptr*)':
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/util/io-util.cc:897:3:
 warning: 'created' may be used uninitialized in this function 
[-Wmaybe-uninitialized]
   if (!created) {
   ^~
{code}

{code}
 54%] Building CXX object 
src/arrow/CMakeFiles/arrow_static.dir/util/logging.cc.obj
In file included from 
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/util/io-util.cc:63:
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/io/mman.h:
 In function 'void* mmap(void*, size_t, int, int, int, off_t)':
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/io/mman.h:94:62:
 warning: right shift count >= width of type [-Wshift-count-overflow]
   const DWORD dwMaxSizeHigh = static_cast((maxSize >> 32) & 
0xL);
  ^~
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/util/io-util.cc:
 In function 'arrow::Status arrow::internal::MemoryMapRemap(void*, size_t, 
size_t, int, void**)':
C:/msys64/home/mingw-packages/mingw-w64-arrow/src/arrow/cpp/src/arrow/util/io-util.cc:568:55:
 warning: right shift count >= width of type [-Wshift-count-overflow]
   LONG new_size_high = static_cast((new_size >> 32) & 0xL);
 
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] C++ SO versioning with 1.0.0

[Krisztián Szűcs]

Created a PR with the versioning scheme described by @Kou.
https://github.com/apache/arrow/pull/4801

We can change later (but before the next release) to unblock
the failing CI builds.

On Thu, Jul 4, 2019 at 12:51 PM Antoine Pitrou  wrote:

> On Thu, 4 Jul 2019 09:50:10 +0200
> Krisztián Szűcs  wrote:
> > Could We add a temporary solution and perhaps change the versioning
> schema
> > later?
> > I'm asking because all of our c++ based CI builds are failing now.
>
> Wow, thanks for pointing out.
> Indeed:
> https://travis-ci.org/apache/arrow/builds/554118250
>
> """
> CMake Error at CMakeLists.txt:47 (message):
>   Need to implement SO version generation for Arrow 1.0+
> -- Configuring incomplete, errors occurred!
> """
>
> Regards
>
> Antoine.
>
>
>

[jira] [Created] (ARROW-5848) [C++] SO versioning schema after release 1.0.0

[Krisztian Szucs (JIRA)]

Krisztian Szucs created ARROW-5848:
--

 Summary: [C++] SO versioning schema after release 1.0.0
 Key: ARROW-5848
 URL: https://issues.apache.org/jira/browse/ARROW-5848
 Project: Apache Arrow
  Issue Type: Bug
  Components: C++
Affects Versions: 1.0.0
Reporter: Krisztian Szucs
Assignee: Krisztian Szucs


Described by [~kou] on the mailing list:

If we may break ABI compatibility each minor version up
release ("Y" is increased in "X.Y.Z"), we should include
minor version into SO major version (100, 101 and 102 in the
following examples):

  * 1.0.0 -> libarrow.100.0.0
  * 1.1.0 -> libarrow.101.0.0
  * 1.2.0 -> libarrow.102.0.0

If we don't break ABI compatibility each minor version up
release, we just use the same SO major version (100 in the
following examples) in 1.0.0:

  * 1.0.0 -> libarrow.100.0.0
  * 1.1.0 -> libarrow.100.1.0
  * 1.2.0 -> libarrow.100.2.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-5847) [C++] Remove lazy.h

[Antoine Pitrou (JIRA)]

Antoine Pitrou created ARROW-5847:
-

 Summary: [C++] Remove lazy.h
 Key: ARROW-5847
 URL: https://issues.apache.org/jira/browse/ARROW-5847
 Project: Apache Arrow
  Issue Type: Task
  Components: C++
Reporter: Antoine Pitrou


This header file, its tests and benchmarks, are unused. Remove them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] C++ SO versioning with 1.0.0

[Antoine Pitrou]

On Thu, 4 Jul 2019 09:50:10 +0200
Krisztián Szűcs  wrote:
> Could We add a temporary solution and perhaps change the versioning schema
> later?
> I'm asking because all of our c++ based CI builds are failing now.

Wow, thanks for pointing out.
Indeed:
https://travis-ci.org/apache/arrow/builds/554118250

"""
CMake Error at CMakeLists.txt:47 (message):
  Need to implement SO version generation for Arrow 1.0+
-- Configuring incomplete, errors occurred!
"""

Regards

Antoine.

[jira] [Created] (ARROW-5846) [Java] Create Avro adapter module and add dependencies

[Ji Liu (JIRA)]

Ji Liu created ARROW-5846:
-

 Summary: [Java] Create Avro adapter module and add dependencies
 Key: ARROW-5846
 URL: https://issues.apache.org/jira/browse/ARROW-5846
 Project: Apache Arrow
  Issue Type: Sub-task
Reporter: Ji Liu
Assignee: Ji Liu






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-5845) [Java] Implement converter between Arrow record batches and Avro records

[Ji Liu (JIRA)]

Ji Liu created ARROW-5845:
-

 Summary: [Java] Implement converter between Arrow record batches 
and Avro records
 Key: ARROW-5845
 URL: https://issues.apache.org/jira/browse/ARROW-5845
 Project: Apache Arrow
  Issue Type: New Feature
  Components: Java
Reporter: Ji Liu
Assignee: Ji Liu






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-5844) [Java] Support comparison & sort for more numeric types

[Liya Fan (JIRA)]

Liya Fan created ARROW-5844:
---

 Summary: [Java] Support comparison & sort for more numeric types
 Key: ARROW-5844
 URL: https://issues.apache.org/jira/browse/ARROW-5844
 Project: Apache Arrow
  Issue Type: New Feature
  Components: Java
Reporter: Liya Fan
Assignee: Liya Fan


Currently, we only support comparison & sort for 32-bit integers, in this 
issue, we provide support for more numeric data types:
* byte
* short
* long
* float
* double



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARROW-5843) [Java] Improve the readability and performance of BitVectorHelper#getNullCount

[Liya Fan (JIRA)]

Liya Fan created ARROW-5843:
---

 Summary: [Java] Improve the readability and performance of 
BitVectorHelper#getNullCount
 Key: ARROW-5843
 URL: https://issues.apache.org/jira/browse/ARROW-5843
 Project: Apache Arrow
  Issue Type: Improvement
  Components: Java
Reporter: Liya Fan
Assignee: Liya Fan


Improve the performance by:
1. Count the number of 1 bits by long or int, instead of by byte
2. If the number of value count is a multiple of 8, there is no need to process 
the last byte separately. This makes the code clearer. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [RESULT][VOTE] Release Apache Arrow 0.14.0 - RC0

[Sutou Kouhei]

Thanks!

Please see my note in other e-mail:

>* We need to add Flight support
>* We need to remove -D*_HOME and use system libraries as
>  much as possible

In <95846f16-84c6-4cbe-8fe1-b16e73faf...@gmail.com>
  "Re: [RESULT][VOTE] Release Apache Arrow 0.14.0 - RC0" on Thu, 4 Jul 2019 
16:40:28 +0900,
  Yosuke Shiro  wrote:

> I'll update Homebrew packages.
> 
> 
>> On Jul 4, 2019, at 14:49, Sutou Kouhei  wrote:
>> 
>> Hi,
>> 
>> The 0.14.0 RC0 vote carries with 4 binding +1 votes. Thanks
>> for helping verify the RC.
>> 
>> There are some post release tasks:
>> 
>>  
>> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Post-releasetasks
>> 
>> I'll rebase the master branch. Could someone help doing
>> these tasks?
>> 
>> 
>> Thanks,
>> --
>> kou
> 

Re: [RESULT][VOTE] Release Apache Arrow 0.14.0 - RC0

[Sutou Kouhei]

Thanks!

In 
  "Re: [RESULT][VOTE] Release Apache Arrow 0.14.0 - RC0" on Thu, 4 Jul 2019 
09:32:55 +0200,
  Krisztián Szűcs  wrote:

> I will handle the conda-forge packages.
> 
> On Thu, Jul 4, 2019 at 7:49 AM Sutou Kouhei  wrote:
> 
>> Hi,
>>
>> The 0.14.0 RC0 vote carries with 4 binding +1 votes. Thanks
>> for helping verify the RC.
>>
>> There are some post release tasks:
>>
>>
>> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Post-releasetasks
>>
>> I'll rebase the master branch. Could someone help doing
>> these tasks?
>>
>>
>> Thanks,
>> --
>> kou
>>

Re: [DISCUSS] C++ SO versioning with 1.0.0

[Krisztián Szűcs]

Could We add a temporary solution and perhaps change the versioning schema
later?
I'm asking because all of our c++ based CI builds are failing now.

On Wed, Jul 3, 2019 at 10:51 PM Antoine Pitrou  wrote:

>
> The question: is do we want to maintain a stable ABI?
>
> Given the number of constraints that we already impose ourselves, I
> think I'm -1 on establishing a stable ABI for now.
>
> So we should probably bump the SO number on each minor release.
>
> Regards
>
> Antoine.
>
>
> Le 03/07/2019 à 22:41, Uwe L. Korn a écrit :
> > I've documented that some time ago:
> https://github.com/apache/arrow/blob/master/docs/source/developers/cpp.rst
> >
> > I actually wanted to add this to the build but we were breaking the ABI
> so often that it would have never been green.
> >
> > Uwe
> >
> > On Wed, Jul 3, 2019, at 9:52 PM, Sutou Kouhei wrote:
> >> Ruby uses ABI Compliance Checker
> >> https://lvc.github.io/abi-compliance-checker/
> >> with a small script:
> >>
> >>   https://github.com/ruby/chkbuild/blob/master/abi-checker.rb
> >>
> >> There is the official Debian package for it:
> >>
> >>   https://packages.debian.org/search?keywords=abi-compliance-checker
> >>
> >> In <20c3b917-6f80-ca14-669d-f89e7ec7f...@python.org>
> >>   "Re: [DISCUSS] C++ SO versioning with 1.0.0" on Wed, 3 Jul 2019
> >> 09:59:15 +0200,
> >>   Antoine Pitrou  wrote:
> >>
> >>>
> >>> Do we have any reliable tool to check for ABI breakage?
> >>>
> >>>
> >>> Le 03/07/2019 à 02:57, Sutou Kouhei a écrit :
>  Hi,
> 
>  We'll release 0.14.0 soon. Then we use "1.0.0-SNAPSHOT" at
>  master. If we use "1.0.0-SNAPSHOT", C++ build is failed:
> 
>  https://github.com/apache/arrow/blob/master/cpp/CMakeLists.txt#L47
> 
>    message(FATAL_ERROR "Need to implement SO version generation for
> Arrow 1.0+")
> 
>  So we need to consider how to generate SO version for 1.0.0
>  as the first task for 1.0.0.
> 
>  See also https://issues.apache.org/jira/browse/ARROW-2522
>  for the current SO versioning.
> 
> 
>  If we may break ABI compatibility each minor version up
>  release ("Y" is increased in "X.Y.Z"), we should include
>  minor version into SO major version (100, 101 and 102 in the
>  following examples):
> 
>    * 1.0.0 -> libarrow.100.0.0
>    * 1.1.0 -> libarrow.101.0.0
>    * 1.2.0 -> libarrow.102.0.0
> 
>  If we don't break ABI compatibility each minor version up
>  release, we just use the same SO major version (100 in the
>  following examples) in 1.0.0:
> 
>    * 1.0.0 -> libarrow.100.0.0
>    * 1.1.0 -> libarrow.100.1.0
>    * 1.2.0 -> libarrow.100.2.0
> 
> 
>  I choose 1XX as SO major version because we already use
>  10-14 for SO major version. We should not use them in the
>  future to avoid confusion. So I choose 1XX in the above
>  examples.
> 
> 
>  Any thoughts?
> 
> 
>  Thanks,
>  --
>  kou
> 
> >>
>

Re: [RESULT][VOTE] Release Apache Arrow 0.14.0 - RC0

[Sutou Kouhei]

Hi,

I need your help!
Could Rust developers see "Failed:" section?
Could someone take over tasks in "Need helped:" section?

Failed:

  * Updating Rust packages

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingRustpackages

* We need the following patch:


diff --git a/dev/release/post-07-rust.sh b/dev/release/post-07-rust.sh
index a2f6e2988..c632fa793 100755
--- a/dev/release/post-07-rust.sh
+++ b/dev/release/post-07-rust.sh
@@ -53,6 +53,12 @@ curl \
 rm -rf ${archive_name}
 tar xf ${tar_gz}
 modules=()
+  sed \
+-i \
+-E \
+-e 's/^arrow = "([^"]*)"/arrow = { version = "\1", path = "..\/arrow" }/g' 
\
+-e 's/^parquet = "([^"]*)"/parquet = { version = "\1", path = 
"..\/parquet" }/g' \
+${archive_name}/rust/*/Cargo.toml
 for cargo_toml in ${archive_name}/rust/*/Cargo.toml; do
   module_dir=$(dirname ${cargo_toml})
   pushd ${module_dir}


* "INSTALL_RUST=yes dev/release/post-07-rust.sh 0.14.0"
  is failed with the above patch:


   Packaging arrow v0.14.0 
(/home/kou/work/cpp/arrow.kou/apache-arrow-0.14.0/rust/arrow)
   Verifying arrow v0.14.0 
(/home/kou/work/cpp/arrow.kou/apache-arrow-0.14.0/rust/arrow)
error: failed to verify package tarball

Caused by:
  failed to parse manifest at 
`/home/kou/work/cpp/arrow.kou/apache-arrow-0.14.0/rust/target/package/arrow-0.14.0/Cargo.toml`

Caused by:
  can't find `array_from_vec` bench, specify bench.path


* How to solve this?

Done:

  * Rebasing the master branch on local release branch

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Rebasingthemasterbranchonlocalreleasebranch

  * Marking the released version as "RELEASED" on JIRA

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Markingthereleasedversionas%22RELEASED%22onJIRA

  * Starting the new version on JIRA

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-StartingthenewversiononJIRA

  * Partially: Updating the Arrow website

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingtheArrowwebsite

* Release note has been added.
* No blog post.
* Not upload to website yet.

  * Uploading source release artifacts to SVN

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UploadingsourcereleaseartifactstoSVN

  * Uploading binary release artifacts to Bintray

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UploadingbinaryreleaseartifactstoBintray

  * Partially: Announcing release

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Announcingrelease

* Added release date.
* Not send release announce to announce@ and dev@ yet.

  * Partially: Updating C++ and Python packages

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingC++andPythonpackages

* Uploaded to PyPI.
  * Wrote upload shell script but not create pull request yet.
* Not update conda packages yet

  * Updating Java Maven artifacts in Maven central

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingJavaMavenartifactsinMavencentral

  * Updating Ruby packages

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingRubypackages

  * Updating JavaScript packages

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingJavaScriptpackages

  * Updating .NET NuGet packages

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Updating.NETNuGetpackages

  * Removing source artifacts for RC

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-RemovingsourceartifactsforRC

Need help:

  * All pull requests need to rebase on master by
"Rebasing the master branch on local release branch"

  * Blog post

  * Update website

  * Announcing release to announce@ and dev@

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Announcingrelease

  * Updating website with new API documentation

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingwebsitewithnewAPIdocumentation

  * Updating conda packages

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Updatingcondapackages

  * Updating Homebrew packages

https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingHomebrewpackages
* We need to add Flight support
* 

Re: [RESULT][VOTE] Release Apache Arrow 0.14.0 - RC0

[Yosuke Shiro]

I'll update Homebrew packages.


> On Jul 4, 2019, at 14:49, Sutou Kouhei  wrote:
> 
> Hi,
> 
> The 0.14.0 RC0 vote carries with 4 binding +1 votes. Thanks
> for helping verify the RC.
> 
> There are some post release tasks:
> 
>  
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Post-releasetasks
> 
> I'll rebase the master branch. Could someone help doing
> these tasks?
> 
> 
> Thanks,
> --
> kou

[jira] [Created] (ARROW-5842) [Java] Revise the semantic of lastSet in ListVector

[Liya Fan (JIRA)]

Liya Fan created ARROW-5842:
---

 Summary: [Java] Revise the semantic of lastSet in ListVector
 Key: ARROW-5842
 URL: https://issues.apache.org/jira/browse/ARROW-5842
 Project: Apache Arrow
  Issue Type: Bug
  Components: Java
Reporter: Liya Fan
Assignee: Liya Fan


The {{lastSet}} member in ListVector seems misleading. According to the name, 
it should refers to the last index that is actually set. However, from the 
context of the code, it actually means the next index that will be set.

We fix this problem, and make it consistent with the {{lastSet}} in 
{{BaseVariableWidthVector}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [RESULT][VOTE] Release Apache Arrow 0.14.0 - RC0

[Krisztián Szűcs]

I will handle the conda-forge packages.

On Thu, Jul 4, 2019 at 7:49 AM Sutou Kouhei  wrote:

> Hi,
>
> The 0.14.0 RC0 vote carries with 4 binding +1 votes. Thanks
> for helping verify the RC.
>
> There are some post release tasks:
>
>
> https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Post-releasetasks
>
> I'll rebase the master branch. Could someone help doing
> these tasks?
>
>
> Thanks,
> --
> kou
>

[jira] [Created] (ARROW-5841) [Website] Add 0.14.0 release note

[Sutou Kouhei (JIRA)]

Sutou Kouhei created ARROW-5841:
---

 Summary: [Website] Add 0.14.0 release note
 Key: ARROW-5841
 URL: https://issues.apache.org/jira/browse/ARROW-5841
 Project: Apache Arrow
  Issue Type: Task
  Components: Website
Reporter: Sutou Kouhei
Assignee: Sutou Kouhei
 Fix For: 0.14.0






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)