+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, > > > > > >> > > > > > > > >
