Hi,
I agree with Jacob's proposal, and also share the concern with Kou.
IMHO, it would be great to have several potential release managers. On
some other Apache projects, we had a kind of release bottleneck with a
very limited number of release managers. Maybe it would be interesting
to have revie
+1 (non binding)
It sounds good to me. Maybe with to update documentation ?
Thanks
Regards
JB
On Wed, Apr 3, 2024 at 1:01 PM Joel Lubinitsky wrote:
>
> Hello,
>
> I would like to propose a change to the ADBC specification that introduces
> 5 new standard info codes and formalizes 3 existing opt
+1
On Sat, Apr 6, 2024, at 22:20, Matt Topol wrote:
> +1
>
> On Sat, Apr 6, 2024, 4:54 AM Andrew Lamb wrote:
>
>> +1
>>
>> On Fri, Apr 5, 2024 at 9:55 PM Jacob Wujciak
>> wrote:
>>
>> > + 1 (non-binding)
>> >
>> > Am Sa., 6. Apr. 2024 um 01:57 Uhr schrieb Joel Lubinitsky <
>> > joell...@gmail.co
Hi,
I don't object this but I'm worry about we have enough
release managers for each component. Here are components:
* C/GLib (me but I want to release C++ and C/GLib together
for .deb/.rpm packages)
* C++ (Raúl and me)
* C# (Curt?)
* Go (Matt?)
* Java (David?)
* JavaScript (Dominik?)
* MATLAB
Le 28/03/2024 à 21:42, Jacob Wujciak a écrit :
For Arrow C++ bindings like Arrow R and PyArrow having distinct versions
would require additional work to both enable the use of different versions
and ensure version compatibility is monitored and potentially updated if
needed.
We could simply
I agree with all the other comments on this thread
Having smaller releases is key to being able to release more frequently and
finding the relevant expertise in my opinion.
We have had separate releases / votes for Arrow Rust (and Arrow DataFusion)
and it has served us quite well. The version sch
