Hi,
The vote has been opened for 4 days, currently the vote is:
1 +1 binding
3 +1 non-binding votes
Can I get some PMCs to verify the release?
Thanks,
Raúl
El vie, 18 ago 2023 a las 23:18, Rok Mihevc () escribió:
>
> Successfully tested sources (except Python due to an odd and probably
> harml
Hello,
It seems the verification instructions are not up to date?
https://cwiki.apache.org/confluence/display/ARROW/How+to+Verify+Release+Candidates
I've tried to run the suggested command:
$ dev/release/verify-release-candidate.sh source 13.0.0 3
and I get the following error message:
"""
U
Hello,
Abiding by the Apache Software Foundation's guidelines, every Arrow
release is voted on and requires at least 3 "binding" votes to be approved.
Also, every Arrow release vote is accompanied by a little ceremonial
where contributors and core developers run a release verification scrip
+1 from me (binding). The verification script failed for me, but I
consider it not a problem (see separate discussion thread).
Regards
Antoine.
Le 18/08/2023 à 10:00, Raúl Cumplido a écrit :
Hi,
I would like to propose the following release candidate (RC3) of Apache
Arrow version 13.0.0.
The Rust arrow implementation (arrow-rs) and DataFusion also use release
verification scripts, mostly inherited from when they were split from the
mono repo. They have found issues from time to time, for us, but those
issues are often not platform related and have not been release blockers.
Thankf
Hi,
I do agree that currently verifying the release locally provides
little benefit for the effort we have to put in but I thought this was
required as per Apache policy:
https://www.apache.org/legal/release-policy.html#release-approval
Copying the important bit:
"""
Before casting +1 binding vot
+1
(Sorry. I forgot to complete my verification.)
I ran the followings on Debian GNU/Linux sid:
* TEST_DEFAULT=0 \
TEST_SOURCE=1 \
LANG=C \
TZ=UTC \
CUDAToolkit_ROOT=/usr \
ARROW_CMAKE_OPTIONS="-DBoost_NO_BOOST_CMAKE=ON -Dxsimd_SOURCE=BUNDLED" \
dev/release/
Hi,
I've created a "MATLAB" project: https://github.com/orgs/apache/projects/289
All Arrow committers have "Admin" role.
Could you try it?
Thanks,
--
kou
In
"[MATLAB] Using GitHub Projects for Project Planning" on Mon, 21 Aug 2023
19:28:15 +,
Kevin Gurney wrote:
> Hi All,
>
> Sar
Hi,
I notice that this project can be seen directly from Apache's github
page[1], with no indication of Arrow. It seems like the Github Project is
organization level v.s. repo level. I fear the naming may cause confusion
for people from other Apache projects.
[1] https://github.com/orgs/apache/pr
+1
On Mon, 21 Aug 2023 at 19:33, Weston Pace wrote:
>
> +1
>
> Thanks to all for the discussion and thanks to Ben for all of the great
> work.
>
>
> On Mon, Aug 21, 2023 at 9:16 AM wish maple wrote:
>
> > +1 (non-binding)
> >
> > It would help a lot when processing UTF-8 related data!
> >
> > Xu
To Jin's point - namespacing like "Arrow MATLAB" would prevent confusion.
We have prior art of "Arrow ADBC Initial Release" [1].
Rok
[1] https://github.com/orgs/apache/projects/159
On Tue, Aug 22, 2023 at 1:31 PM Jin Shang wrote:
> Hi,
>
> I notice that this project can be seen directly from A
I am also in favour of changes to the verification scripts. This is a bit
of a tangent but has direct implications for our entire release process so
I will bring it up first. While re-reading the general release policy I
came across this new addition (made in late july):
> All supplied packages MU
If the main impetus for the verification script is to comply with ASF
requirements, probably the script can be made much simpler, such as just
verify the GPG signatures are valid? Or perhaps this can be achieved
without a script at all.
The irony is that, however complex, our verification s
Compiled code usually means binaries you can’t derive in a deterministic,
verifiable way from the source code *shipped next to it*. So in this case
any developer should be able to reproduce the flatbuffers output from the
release package only.
“Caches”, multi stage compilation etc should be ok.
B
Hi,
I would like to propose a release of Apache Arrow DataFusion Implementation,
version 30.0.0.
This release candidate is based on commit:
c703526596c8602f24d470d98c469c985a99b4b5 [1]
The proposed release tarball and signatures are hosted at [2].
The changelog is located at [3].
Please download
Hmm... perhaps Flatbuffers compilation is usually more deterministic
than compiling C++ code into machine code, but that's mainly (AFAIK)
because the transformation step is much simpler in the former case, than
in the latter. The Flatbuffers compiler also has a range of options that
influenc
And of course this is a bit pedantic, and only important if we want to
comply with *the letter* of the ASF policies. My own personal opinion is
that complying in spirit is enough (but I'm also not sure I understand
the ASF's spirit :-)).
Regards
Antoine.
Le 22/08/2023 à 17:10, Antoine Pi
+1 (binding)
Verified on M1 Mac.
Thanks Andy.
On Tue, Aug 22, 2023 at 7:48 AM Andy Grove wrote:
>
> Hi,
>
> I would like to propose a release of Apache Arrow DataFusion Implementation,
> version 30.0.0.
>
> This release candidate is based on commit:
> c703526596c8602f24d470d98c469c985a99b4b5 [1
+1 (non-binding)
Successfully ran verification script on ubuntu 22 x86 machine.
Thanks Andy!
- Jeremy Dyer
On Tue, Aug 22, 2023 at 11:26 AM L. C. Hsieh wrote:
> +1 (binding)
>
> Verified on M1 Mac.
>
> Thanks Andy.
>
> On Tue, Aug 22, 2023 at 7:48 AM Andy Grove wrote:
> >
> > Hi,
> >
> > I w
Hi All,
@Kou - thank you very much for creating the GitHub Project!
@Jin and @Rok - you make an excellent point about the namespacing. Also, its
nice to hear that ADBC used GitHub Projects in the past.
I've updated the project name to "Arrow MATLAB".
If anyone has any other flags or suggestion
I would be curious how old that language is in the ASF policy. In the era
of cloud infrastructure and public CI, "your own hardware" might mean
something different than it once did. IMO, it is essential that we download
and test the release artifacts in a separate context from where they are
built
Hi,
Thanks for updating the project name!
--
kou
In
"Re: [MATLAB] Using GitHub Projects for Project Planning" on Tue, 22 Aug 2023
16:03:45 +,
Kevin Gurney wrote:
> Hi All,
>
> @Kou - thank you very much for creating the GitHub Project!
>
> @Jin and @Rok - you make an excellent po
The vote carries with 6 binding +1 votes, 1 non-binding +1 vote, and no
-1/0 votes.
Thanks everyone for participating! We'll get that PR merged.
--Matt
On Wed, Aug 16, 2023, 12:59 PM L. C. Hsieh wrote:
> +1 (binding)
>
> On Wed, Aug 16, 2023 at 9:05 AM Jacob Quinn
> wrote:
> >
> > +1 (binding
+1
Verified on x86 Mac
Thank you Andy -- here is hoping this one successfully can be published!
Andrew
On Tue, Aug 22, 2023 at 11:41 AM Jeremy Dyer wrote:
> +1 (non-binding)
>
> Successfully ran verification script on ubuntu 22 x86 machine.
>
> Thanks Andy!
>
> - Jeremy Dyer
>
> On Tue, Aug 22
Hi,
I agree that we have problems in our release verification
script. But I think that it's useful for us.
> what the verification script is testing for
1. Verify cryptographic signatures of all artifacts
2. Compile source codes and run unit tests
3. Install binary packages and test them
> *why
Hi,
We can ask the ASF about this. memb...@apache.org?
Thanks,
--
kou
In <367f6bb7-d8a5-ea49-f5d8-e4fa1afae...@python.org>
"Re: [Discuss] Do we need a release verification script?" on Tue, 22 Aug 2023
17:18:02 +0200,
Antoine Pitrou wrote:
>
> And of course this is a bit pedantic, and o
26 matches
Mail list logo
