Hi, We can create a new apache/arrow-XXX repository for it. Let's try the approach to determine whether it's easy to maintain or not.
Thanks, -- kou In <can6-e1fsrnacd-fefw-d8glrxk7hcvf07nfvwgby4jmbop4...@mail.gmail.com> "Re: [DISCUSS] Split Java release process" on Tue, 19 Nov 2024 11:16:37 +0800, Ruoxi Sun <zanmato1...@gmail.com> wrote: > +1. > > And a big +1 on Jacob: >> I think now is probably the point where we should look at centralizing > some of these scripts/tools instead of continuing to copy-paste them into > more repos (same for some of the workflows, we can make those re-usable > actions). > > For example when verifying release candidates, it feels weird to run a > script which is under the local arrow repo but has nothing to do with the > rest of the repo (i.e., the code). A separate repo containing the > workflow/scripts/tools could be much more satisfying and better in terms of > re-usability. > > *Regards,* > *Rossi SUN* > > > On Tue, Nov 19, 2024 at 11:01 AM Jacob Wujciak <assignu...@apache.org> > wrote: > >> +1 >> >> Neal makes a great point >> >it makes sense that they should have a release process and cadence that >> matches, and that those that are under active development should be able to >> move ahead more freely. >> >> This also gives a more honest view into the implementation's >> development velocity, which in turn might even increase contributions. >> For example the JavaScript implementation has seen bursts of activity >> and periods of several quarterly releases without any (non-dependabot) >> changes. But every quarter still bumped the major version number >> giving the false impression of constant activity/larger maintainer >> base. Less frequent, properly versioned (i.e. not always major) >> releases mirroring the actual activity might spur interested parties >> to checkout if they can contribute vs. 'Oh new arrow version, cool.'. >> >> (I obviously also agree with Raúl in regards to JS) >> >> Ian: >> > apache/arrow-go given us any clues about this? >> >> At the minimum we have already seen (new) contributors opening >> issues/PRs in the new repo. From a more personal perspective I would >> be much more likely to 'watch' a language specific repo I am >> interested in vs getting spammed by notifications about 11 other >> languages I don't care about. >> >> Kou: >> > We can reuse some release scripts in dev/release/ in apache/arrow like >> we did in apache/arrow-adbc. >> >> I think now is probably the point where we should look at centralizing >> some of these scripts/tools instead of continuing to copy-paste them >> into more repos (same for some of the workflows, we can make those >> re-usable actions). >> >> Jacob >> >> Am Mo., 18. Nov. 2024 um 16:13 Uhr schrieb Ian Cook <ianmc...@apache.org>: >> > >> > There was some informal discussion about this in the biweekly Arrow >> > community meeting on November 6. One concern raised was that >> > implementations outside the monorepo could suffer from an "out of sight, >> > out of mind" problem. For example, because the new apache/arrow-java repo >> > will have many fewer community members watching it compared to the >> > apache/arrow repo, there might be less public participation in issues and >> > PRs. But I don't know whether this will really be a problem in practice. >> > Has our experience moving the Go implementation to apache/arrow-go given >> us >> > any clues about this? >> > >> > Ian >> > >> > On Mon, Nov 18, 2024 at 8:03 AM Neal Richardson < >> neal.p.richard...@gmail.com> >> > wrote: >> > >> > > +1, makes sense to me. Since many of the Arrow libraries are at a more >> > > stable phase of development, it makes sense that they should have a >> release >> > > process and cadence that matches, and that those that are under active >> > > development should be able to move ahead more freely. >> > > >> > > Neal >> > > >> > > >> > > On Mon, Nov 18, 2024 at 3:25 AM Raúl Cumplido <rau...@apache.org> >> wrote: >> > > >> > > > I am also +1 on moving the Java implementation to its own repository. >> > > > >> > > > I am also happy to help with the releases on the Java repository and, >> > > > as with Go, I am also happy to help with some of the migration tasks. >> > > > >> > > > As a side note, in general I tend to have more problems with >> > > > JavaScript when releasing, verifying, etcetera. I would love for >> > > > JavaScript to move to its own repository but here I think we have to >> > > > make a bigger effort on finding committers and PMCs to have an active >> > > > and stable maintenance. >> > > > >> > > > Thanks, >> > > > Raúl >> > > > >> > > > El lun, 18 nov 2024 a las 9:17, David Li (<lidav...@apache.org>) >> > > escribió: >> > > > > >> > > > > While early, it seems to have gone well for Go. The ability to do >> more >> > > > frequent point releases for Java might be interesting. >> > > > > >> > > > > Since the JNI JARs bundle the C++ libraries when built, we can >> build >> > > off >> > > > of the latest released C++ version whenever the Java project needs to >> > > > release, and not have to worry too much about maintaining runtime >> > > > compatibility with multiple versions (only with making sure we aren't >> > > > "caught out" by upstream changes). >> > > > > >> > > > > On Mon, Nov 18, 2024, at 17:07, Gang Wu wrote: >> > > > > > +1 on splitting the Java codebase! >> > > > > > >> > > > > > I'm not an active contributor/reviewer to the Java codebase, >> though I >> > > > have >> > > > > > several contributions to it in the past. I can volunteer to be a >> > > > release >> > > > > > manager >> > > > > > on the Java side if I can help. I have some experience in >> releasing >> > > > orc and >> > > > > > parquet-java in the past. >> > > > > > >> > > > > > Best, >> > > > > > Gang >> > > > > > >> > > > > > On Mon, Nov 18, 2024 at 4:01 PM Antoine Pitrou < >> anto...@python.org> >> > > > wrote: >> > > > > > >> > > > > >> >> > > > > >> Hi Kou, >> > > > > >> >> > > > > >> Thanks a lot for bringing this. >> > > > > >> >> > > > > >> I'm +1 on the principle, both for splitting the Java release >> process >> > > > and >> > > > > >> moving the Java implementation into another repository. >> > > > > >> >> > > > > >> We do need to find more maintainers for Arrow Java, but that is >> true >> > > > > >> regardless of whether the Java implementation stays in the >> monorepo. >> > > > > >> >> > > > > >> (also, I don't know if David Li would like to be described as >> > > > > >> "Java-focused" :-)) >> > > > > >> >> > > > > >> Regards >> > > > > >> >> > > > > >> Antoine. >> > > > > >> >> > > > > >> >> > > > > >> Le 18/11/2024 à 08:55, Sutou Kouhei a écrit : >> > > > > >> > Hi, >> > > > > >> > >> > > > > >> > This is a similar discussion to the "[DISCUSS] Split Go >> > > > > >> > release process" thread: >> > > > > >> > >> https://lists.apache.org/thread/fstyfvzczntt9mpnd4f0b39lzb8cxlyf >> > > > > >> > >> > > > > >> > How about splitting Java release process from other >> > > > > >> > apache/arrow components like apache/arrow-go? Here are >> > > > > >> > some reasons of this proposal: >> > > > > >> > >> > > > > >> > * The Java implementation is a native implementation not >> > > > > >> > bindings >> > > > > >> > * Some modules are the bindings of the C++ implementation >> > > > > >> > but we can support multiple C++ version if needed like >> > > > > >> > the R implementation does >> > > > > >> > * We can simplify apache/arrow release by splitting the Java >> > > > > >> > implementation >> > > > > >> > * We'll be able to use more minor/patch releases for the >> > > > > >> > Java implementation instead of major releases like the Go >> > > > > >> > implementation >> > > > > >> > >> > > > > >> > Here is my idea how to proceed this: >> > > > > >> > >> > > > > >> > 1. Extract java/ in apache/arrow to apache/arrow-java like >> > > > > >> > apache/arrow-go >> > > > > >> > * Filter java/ related commits from apache/arrow and >> create >> > > > > >> > apache/arrow-java with them like we did for >> apache/arrow-go >> > > > > >> > * Remove java/ related codes from apache/arrow >> > > > > >> > 2. Prepare integration test CI like apache/arrow-go does: >> > > > > >> > >> > > > > >> >> > > > >> https://github.com/apache/arrow-go/blob/main/.github/workflows/test.yml >> > > > > >> > 3. Prepare release script based on apache/arrow-go >> > > > > >> > >> > > > > >> > We can reuse some release scripts in dev/release/ in >> > > > > >> > apache/arrow like we did in apache/arrow-adbc. >> > > > > >> > >> > > > > >> > Cons of this idea: >> > > > > >> > >> > > > > >> > * There is only one active Java focused PMC member and >> > > > > >> > committer: David Li >> > > > > >> > * We need to increase active Java focused PMC members and >> > > > > >> > committers for stable maintenance >> > > > > >> > >> > > > > >> > >> > > > > >> > What do you think about this? >> > > > > >> > >> > > > > >> > >> > > > > >> > Thanks, >> > > > > >> >> > > > >> > > >>
