Hi, Thanks for pointing out this! I agree that the R-related CI jobs covers more areas missed by the C++-related CI jobs. Let's add more C++-related CI jobs to cover R use-cases before we revisit splitting R out.
BTW, I remembered that there is a similar discussion when I dropped support for Ubuntu 20.04: https://github.com/apache/arrow/pull/45507#discussion_r1955436604 apache/arrow-java also faced a similar problem. The C++-related CI jobs don't cover build options for JNI. I'll add jobs for it: https://github.com/apache/arrow/issues/45683 Thanks, -- kou In <CAOCv4himzNFYFwx=6-o1szgoeooihrghfthai+gksurjdi4...@mail.gmail.com> "Re: [DISCUSS] Split R release process" on Mon, 3 Mar 2025 09:32:19 -0500, Neal Richardson <neal.p.richard...@gmail.com> wrote: > 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 >>
