Hi, The vote carries with:
5 +1 (binding): Bryce Mecum, Sutou Kouhei, Gang Wu, Raúl Cumplido and Adam Reeve 0 +1 (non-binding): 0 0: 0 -1: I'll start working on the post release tasks: https://arrow.apache.org/docs/dev/developers/release.html#post-release-tasks Thank you very much for the verification votes! Raúl El jue, 9 jul 2026 a las 20:28, L. C. Hsieh (<[email protected]>) escribió: > > Hi Raúl, Antoine, > > Thanks — Raúl's proposal sounds like the right call to me. I agree with > Antoine that rushing the review is the wrong trade-off. > Let's proceed with RC1 as planned > > A 25.0.1 patch release with GH-50327 (and GH-50430 if ready) works well for > the Spark timeline: what matters for Spark 4.2 users is that a release > with the fix exists to upgrade to, and Spark can point to it in the > migration notes. I'll keep working through the reviews at the normal pace. > > Raúl — once the PRs merge, a rough sense of the patch-release timing would > help us coordinate the Spark-side documentation. Thanks for offering > this. > > Best, > Liang-Chi > > > On Wed, Jul 8, 2026 at 11:50 PM Antoine Pitrou <[email protected]> wrote: > > > > > Hi, > > > > Le 09/07/2026 à 00:31, L. C. Hsieh a écrit : > > > > > > I'd like to ask whether the community would consider cancelling RC1 and > > > cutting an RC2 that includes GH-50326 / PR #50327 (making Array.to_pylist > > > convert without per-element Scalars; reworked per Antoine's review and > > > awaiting another pass). > > > > I understand the concern, and I agree this is a long-standing > > performance wart in PyArrow, but adding a last-minute non-trivial > > improvement (for which we will have to rush review) is the best way to > > introduce regressions. > > > > The alternative would be to start the feature freeze over after > > integrating that PR. I don't think that's a tremendous idea (that would > > push back our quarterly release by ~one month), but I don't have a > > strong opinion either. > > > > Regards > > > > Antoine. > > > >
