The final tally is 4 binding +1 votes, 3 non-binding +1 votes, no -1 votes. The vote passes! I'll finishing up responding to any outstanding comments on the PRs and then merge them when ready.
Binding +1: Myself, Dewey, Antoine, David Non-Binding+1: Felipe, Ian, MapleWish Thanks everyone! --Matt On Mon, Oct 28, 2024 at 10:40 PM wish maple <maplewish...@gmail.com> wrote: > +1 (non-binding) > > Best, > Xuwei Fu > > David Li <lidav...@apache.org> 于2024年10月29日周二 07:51写道： > > > +1 (binding) for me > > > > On Sat, Oct 26, 2024, at 10:39, Ian Cook wrote: > > > Oh ok, thanks Matt, I understand. > > > > > > In that case I am +1 on the proposal but I would like to see notes > added > > to > > > the documentation to make this clearer to readers. I created an issue > for > > > this: https://github.com/apache/arrow/issues/44535 > > > > > > Thanks, > > > Ian > > > > > > > > > > > > On Fri, Oct 25, 2024 at 2:54 PM Matt Topol <zotthewiz...@gmail.com> > > wrote: > > > > > >> Given the promises of the C Data Interface, it's not viable to retire > > the > > >> non-device versions of the interfaces. But overall, it's better to > > prefer > > >> only adding new things in terms of the DeviceArray structs to avoid > > >> consumers having to create duplicate interfaces for both ArrowArray > and > > >> ArrowDeviceArray, particularly because the Device version is a > superset > > of > > >> the functionality of the original ArrowArray. > > >> > > >> Overall we want to push consumers to prefer the ArrowDeviceArray > > versions > > >> of interfaces since it can handle both cases (CPU and non-cpu data) > and > > >> avoids the complexities of consumers having to support both with > > duplicate > > >> interfaces going forward. At least that's my opinion on this one. Let > me > > >> know if anyone disagrees > > >> > > >> --Matt > > >> > > >> On Fri, Oct 25, 2024 at 12:21 PM Ian Cook <ianmc...@apache.org> > wrote: > > >> > > >> > Thanks Matt for doing this! > > >> > > > >> > I am +0.5 on the current proposal, because (if I understand > > correctly) it > > >> > adds ArrowAsyncDeviceStreamHandler but does not > > >> > add ArrowAsyncStreamHandler. I recognize that the C Device Stream > > >> Interface > > >> > with a DeviceType of CPU is functionally equivalent to the C Stream > > >> > Interface, but shouldn't we specify, document, implement the > > non-device > > >> > version of the async interface for completeness and consistency? > > Please > > >> > correct me if I am misunderstanding anything here. > > >> > > > >> > Ian > > >> > > > >> > > > >> > On Fri, Oct 25, 2024 at 10:38 AM Matt Topol <zotthewiz...@gmail.com > > > > >> > wrote: > > >> > > > >> > > @pitrou I've updated the format PR to add the Experimental tag to > > the > > >> > > header and the documentation. Thanks! > > >> > > > > >> > > On Fri, Oct 25, 2024, 7:35 AM Antoine Pitrou <anto...@python.org> > > >> wrote: > > >> > > > > >> > > > > > >> > > > +1, with the same comments as Felipe and Dewey. > > >> > > > > > >> > > > Just at one condition from me: the API should be marked > > experimental. > > >> > > > > > >> > > > Regards > > >> > > > > > >> > > > Antoine. > > >> > > > > > >> > > > > > >> > > > Le 24/10/2024 à 23:17, Felipe Oliveira Carvalho a écrit : > > >> > > > > +1 from me. > > >> > > > > > > >> > > > > I reviewed the PR some time ago and it's not a trivial > protocol, > > >> but > > >> > > the > > >> > > > > complexity seems warranted and necessary. > > >> > > > > > > >> > > > > On Thu, Oct 24, 2024 at 6:02 PM Dewey Dunnington > > >> > > > > <de...@voltrondata.com.invalid> wrote: > > >> > > > > > > >> > > > >> Thanks Matt for putting this together! > > >> > > > >> > > >> > > > >> I was initially concerned about the complexity of the > proposal; > > >> > > > >> however, it is a difficult interaction to standardize and > this > > >> > > > >> proposal is not so complex that it is unimplementable. I am > > >> excited > > >> > to > > >> > > > >> use this to improve our asynchronous database access story in > > the > > >> R > > >> > > > >> ADBC bindings. > > >> > > > >> > > >> > > > >> +1 from me! > > >> > > > >> > > >> > > > >> -dewey > > >> > > > >> > > >> > > > >> On Wed, Oct 23, 2024 at 1:28 PM Matt Topol < > > >> zotthewiz...@gmail.com> > > >> > > > wrote: > > >> > > > >>> > > >> > > > >>> Hey All, > > >> > > > >>> > > >> > > > >>> I would like to propose a vote for us to officially add and > > adopt > > >> > > Async > > >> > > > >>> structures for the Arrow C Data Interface. The proposal can > be > > >> > found, > > >> > > > >> along > > >> > > > >>> with discussion in comment threads, at [1]. The proposal > > contains > > >> > the > > >> > > > >>> definitions and additions to the documentation for the > > website. > > >> > > > >>> > > >> > > > >>> As is required, there are two implementations filed as PRs, > a > > C++ > > >> > > > >>> implementation [2] and a Go implementation [3]. > > >> > > > >>> > > >> > > > >>> The vote will be open for at least 72 hours. > > >> > > > >>> > > >> > > > >>> [ ] +1 Accept the proposal > > >> > > > >>> [ ] +0 > > >> > > > >>> [ ] -1 Do not accept this proposal because... > > >> > > > >>> > > >> > > > >>> Thanks everyone! > > >> > > > >>> --Matt > > >> > > > >>> > > >> > > > >>> [1]: https://github.com/apache/arrow/pull/43632 > > >> > > > >>> [2]: https://github.com/apache/arrow/pull/44495 > > >> > > > >>> [3]: https://github.com/apache/arrow-go/pull/169 > > >> > > > >> > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >
