+1 (binding)
In <20241122.102452.1575817907085915519@clear-code.com>
"Re: [DISCUSS] Split Java release process" on Fri, 22 Nov 2024 10:24:52 +0900
(JST),
Sutou Kouhei wrote:
> Hi,
>
> Thanks all. It seems that we could collect all opinions for
> this pro
Hi,
Thanks all. It seems that we could collect all opinions for
this proposal. I'll start a vote for this proposal.
Thanks,
--
kou
In <20241118.165504.963500056633602181@clear-code.com>
"[DISCUSS] Split Java release process" on Mon, 18 Nov 2024 16:55:04 +0900
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
"Re: [DISCUSS] Split Java release process" on Tue, 19 Nov 2024 11:16:37 +0800,
Ruoxi Sun wrote:
> +1.
>
>
enance.
>
> OK. Let's discuss this in a separated new thread. Could you
> start a new thread?
>
Sounds good to me, let's go one implementation at a time. I'd rather
wait to move Java and once this is done start discussing about JS.
>
> Thanks,
> --
> kou
>
Thanks Kou and Jacob—great points.
+1 from me.
Ian
On Mon, Nov 18, 2024 at 10:01 PM Jacob Wujciak
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
>
+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 candid
+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
ically?
https://github.com/apache/arrow/issues/14796
If we have apache/arrow-java, contributors who are
interested in the Java implementation can watch all
issues/PRs in apache/arrow-java instead of filtering Java
related issues/PRs in apache/arrow.
Thanks,
--
kou
In
"Re: [DISCUS
uld 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.
OK. Let's discuss this in a separated new thread. Could you
start a new thread?
Thanks,
--
kou
In
it will work well.
Thanks,
--
kou
In
"Re: [DISCUSS] Split Java release process" on Mon, 18 Nov 2024 16:07:59 +0800,
Gang Wu wrote:
> +1 on splitting the Java codebase!
>
> I'm not an active contributor/reviewer to the Java codebase, though I have
> several cont
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 co
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
+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, 202
+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
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,
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 w
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 Ja
17 matches
Mail list logo
