Hi Jon, Thanks for the note! I missed the consensus.
Thanks, -- kou In <cae+qdjahffzwwvhk9ooerzft6ah-k6snn9v6q6t_vboyac7...@mail.gmail.com> "Re: [DISCUSS] Split R release process" on Mon, 3 Mar 2025 10:15:29 -0600, Jonathan Keane <jke...@gmail.com> wrote: > I agree with others and don't see much upside to splitting right now. > > One small additional note: "The R bindings can also work with old C++ > versions" is technically true, for some version (pairs), but it turns out > enforcing this is awkward, and the consensus [1] (so far) is that we > actually want to pull back on this and go back to "the versions must match" > and folks are on their own if they need to do that. > > -Jon > > [1] https://github.com/apache/arrow/issues/43623 > > On Mon, Mar 3, 2025 at 8:44 AM Antoine Pitrou <anto...@python.org> wrote: > >> >> I agree with Neal that the decoupling is less obviously desirable on the >> R side. About the number of R-related CI jobs, is there still a need for >> testing so many different configurations? >> >> >> Le 03/03/2025 à 15:32, Neal Richardson a écrit : >> > Thanks for raising this, Kou. I'm personally torn on this because I see >> > some of the upsides of splitting R out, particularly at the project's >> state >> > of maturity, but it's also not as simple as Rust or Java or others we've >> > split out in the past because of the hard dependency on the C++ >> libraries. >> > It's not just about integration testing the IPC format. >> > >> > For better or worse, I can remember tons of instances where the R-related >> > CI jobs have caught something in a C++ PR because they test with >> different >> > compilers and toolchains. If we split the projects and all of the R CI >> jobs >> > are only running on the arrow-r repo, does that mean that the R >> maintainers >> > will be continually finding CI failures in the tests that build with the >> > latest version of the C++ library and filing bug reports back for the C++ >> > project? Either way, it seems that the monorepo would want to keep some R >> > testing jobs in crossbow to be able to validate changes, at least to be >> > able to confirm that the PR for the issue that the R maintainers filed >> > fixes the issue. Maybe this is the way it should be, but it's not clear >> > that it reduces the collective maintenance burden. >> > >> > Just my thoughts based on the historical perspective, I'm happy to defer >> to >> > the judgment of those who are currently shouldering that maintenance >> burden. >> > >> > Neal >> > >> > On Sun, Mar 2, 2025 at 7:53 PM Sutou Kouhei <k...@clear-code.com> wrote: >> > >> >> Hi, >> >> >> >> This is a similar discussion to the "[DISCUSS] Split Go >> >> release process" thread[1] and the "[DISCUSS] Split Java >> >> release process" thread[2]: >> >> >> >> [1] https://lists.apache.org/thread/fstyfvzczntt9mpnd4f0b39lzb8cxlyf >> >> [2] https://lists.apache.org/thread/b99wp2f3rjhy09sx7jqvrfqjkqn9lnyy >> >> >> >> We've split them and they were released from separated >> >> repositories. >> >> >> >> Let's discuss the next target. >> >> >> >> We raised JavaScript as the next candidate in the Java >> >> discussion[3] but we may not find one or more active release >> >> managers for JavaScript. >> >> >> >> [3] https://lists.apache.org/thread/bdko84zy72nlg3k82t772f7pq6zpd0sz >> >> >> >> I propose R as the next candidate because: >> >> >> >> * We have many active committers and PMC members who can >> >> focus on R >> >> * The current R release process is semi-separated >> >> * In general, we release R packages to CRAN by non-trivial >> >> release process after our monorepo release. >> >> e.g.: https://github.com/apache/arrow/issues/45581 >> >> * The R bindings can also work with old C++ versions >> >> * The R bindings don't need to align with the monorepo >> >> versioning. The R bindings can avoid major version up >> >> per 3-4 months. >> >> * We have many R related CI jobs. If we split the R >> >> bindings, we can remove many CI jobs from monorepo. >> >> >> >> >> >> What do you think about this? >> >> >> >> >> >> Thanks, >> >> -- >> >> kou >> >> >> > >>
