You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by GitBox <gi...@apache.org> on 2022/01/17 16:20:13 UTC
[GitHub] [arrow-julia] kiszk opened a new pull request #278: Create CONTRIBUTING.md
kiszk opened a new pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278
This PR addresses #270 by preparing `CONTRIBUTING.md`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] ericphanson commented on pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
ericphanson commented on pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#issuecomment-1019595553
Thanks for the helpful list and the link to the shell script. To answer your questions,
1. No, we don’t prepare binary packages. Julia works by JIT compiling the source at runtime via the `julia` binary, so we only distribute source code.
For some more context, this distribution is usually done via Julia’s package manager; when we “register” the package, we supply the registry with a git-tree-sha of the source tree of the code being registered (this is automated), and the package manager Pkg.jl grabs that tree from the git repo and serves that to users. (Or more accurately, a “storage server” does the grabbing from GitHub or where ever the repo is hosted and stores the source code indefinitely, e.g. in case the original host goes down, and user-facing “package servers” sit in front and serve the code to users through Pkg.jl).
2. Sure, I would be interested in joining in the future.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] kiszk commented on pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
kiszk commented on pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#issuecomment-1014707871
The first commit is a springboard. I really appreciate any comments, questions, and updates from everyone.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] ericphanson edited a comment on pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
ericphanson edited a comment on pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#issuecomment-1019595553
Thanks for the helpful list and the link to the shell script. To answer your questions,
1. No, we don’t prepare binary packages. Julia works by JIT compiling the source at runtime via the `julia` binary, so we only distribute source code.
For some more context, this distribution is usually done via Julia’s package manager; when we “register” the package, we supply the registry with a git-tree-sha of the source tree of the code being registered (this is automated), and the package manager Pkg.jl grabs that tree from the git repo and serves that to users. (Or more accurately, a “storage server” does the grabbing from GitHub or where ever the repo is hosted and stores the source code indefinitely, e.g. in case the original host goes down, and user-facing “package servers” sit in front and serve the code to users through Pkg.jl).
2. Sure, I would be interested in joining in the future.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] kou commented on a change in pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
kou commented on a change in pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#discussion_r787170086
##########
File path: CONTRIBUTING.md
##########
@@ -0,0 +1,37 @@
+# How to contribute Apache Arrow Julia
+
+## Did you find a bug or have an improvement?
+
+We recommend you first search among existing [Github issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
+
+
+## How do you write a patch that fixes a bug or brings an improvement?
+If you cannot find the same idea in the issues, you first need to write a GitHub issue (e.g. [issues in Arrow-julia](https://github.com/apache/arrow-julia/issues)) for a bug fix or planned features for the improvement. To write an issue would help the community have visibility and opportunities for collaborations before a pull request (PR) shows up. This is for the [Apache way](http://theapacheway.com/). We can use GitHub labels to identify bugs.
+It should not be necessary to file an issue for some non-code changes, such as CI changes or minor documentation updates such as fixing typos.
+
+After writing the issue, you may want to write a code by creating [a PR](https://github.com/apache/arrow-julia/pulls). In the PR, it is preferable to refer to the issue number (e.g. `#1`) that you already created.
+
+
+## Do you want to propose a significant new feature or an important refactoring?
+
+We ask that all discussions about major changes in the codebase happen publicly on the [arrow-dev mailing-list](https://lists.apache.org/list.html?dev@arrow.apache.org).
Review comment:
I think that we can GitHub issues and/or arrow-dev mailing list.
We can keep ["Open" in Apache way](http://theapacheway.com/open/) on GitHub issues like other bug reports and feature requests.
@quinnj What do you think about this?
##########
File path: CONTRIBUTING.md
##########
@@ -0,0 +1,37 @@
+# How to contribute Apache Arrow Julia
+
+## Did you find a bug or have an improvement?
+
+We recommend you first search among existing [Github issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
Review comment:
```suggestion
We recommend you first search among existing [GitHub issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
```
##########
File path: CONTRIBUTING.md
##########
@@ -0,0 +1,37 @@
+# How to contribute Apache Arrow Julia
+
+## Did you find a bug or have an improvement?
+
+We recommend you first search among existing [Github issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
+
+
+## How do you write a patch that fixes a bug or brings an improvement?
+If you cannot find the same idea in the issues, you first need to write a GitHub issue (e.g. [issues in Arrow-julia](https://github.com/apache/arrow-julia/issues)) for a bug fix or planned features for the improvement. To write an issue would help the community have visibility and opportunities for collaborations before a pull request (PR) shows up. This is for the [Apache way](http://theapacheway.com/). We can use GitHub labels to identify bugs.
Review comment:
```suggestion
If you cannot find the same idea in the issues, you first need to write a GitHub issue (e.g. [issues in apache/arrow-julia](https://github.com/apache/arrow-julia/issues)) for a bug fix or planned features for the improvement. To write an issue would help the community have visibility and opportunities for collaborations before a pull request (PR) shows up. This is for the [Apache way](http://theapacheway.com/). We can use GitHub labels to identify bugs.
```
##########
File path: CONTRIBUTING.md
##########
@@ -0,0 +1,37 @@
+# How to contribute Apache Arrow Julia
+
+## Did you find a bug or have an improvement?
+
+We recommend you first search among existing [Github issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
+
+
+## How do you write a patch that fixes a bug or brings an improvement?
+If you cannot find the same idea in the issues, you first need to write a GitHub issue (e.g. [issues in Arrow-julia](https://github.com/apache/arrow-julia/issues)) for a bug fix or planned features for the improvement. To write an issue would help the community have visibility and opportunities for collaborations before a pull request (PR) shows up. This is for the [Apache way](http://theapacheway.com/). We can use GitHub labels to identify bugs.
+It should not be necessary to file an issue for some non-code changes, such as CI changes or minor documentation updates such as fixing typos.
+
+After writing the issue, you may want to write a code by creating [a PR](https://github.com/apache/arrow-julia/pulls). In the PR, it is preferable to refer to the issue number (e.g. `#1`) that you already created.
+
+
+## Do you want to propose a significant new feature or an important refactoring?
+
+We ask that all discussions about major changes in the codebase happen publicly on the [arrow-dev mailing-list](https://lists.apache.org/list.html?dev@arrow.apache.org).
+
+
+## Do you have questions about the source code, the build procedure or the development process?
+
+You can also ask on the mailing-list, see above.
+
+
+## Local Development
+
+When developing on Arrow.jl it is recommended that you run the following to ensure that any changes to ArrowTypes.jl are immediately available to Arrow.jl without requiring a release:
+
+```
+julia --project -e 'using Pkg; Pkg.develop(path="src/ArrowTypes")'
+```
+
+
+## Release cycle
+
+The Julia community would like an independent release cycle. Release for apache/arrow doesn't include the Julia implementation. The Julia implementation uses separated version scheme. (apache/arrow uses 6.0.0 as the next version but the next Julia implementation release doesn't use 6.0.0.)
Review comment:
6.0.0 has been released. So the example may confuse.
```suggestion
The Julia community would like an independent release cycle. Release for apache/arrow doesn't include the Julia implementation. The Julia implementation uses separated version scheme.
```
##########
File path: CONTRIBUTING.md
##########
@@ -0,0 +1,37 @@
+# How to contribute Apache Arrow Julia
+
+## Did you find a bug or have an improvement?
+
+We recommend you first search among existing [Github issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
+
+
+## How do you write a patch that fixes a bug or brings an improvement?
+If you cannot find the same idea in the issues, you first need to write a GitHub issue (e.g. [issues in Arrow-julia](https://github.com/apache/arrow-julia/issues)) for a bug fix or planned features for the improvement. To write an issue would help the community have visibility and opportunities for collaborations before a pull request (PR) shows up. This is for the [Apache way](http://theapacheway.com/). We can use GitHub labels to identify bugs.
+It should not be necessary to file an issue for some non-code changes, such as CI changes or minor documentation updates such as fixing typos.
+
+After writing the issue, you may want to write a code by creating [a PR](https://github.com/apache/arrow-julia/pulls). In the PR, it is preferable to refer to the issue number (e.g. `#1`) that you already created.
+
+
+## Do you want to propose a significant new feature or an important refactoring?
+
+We ask that all discussions about major changes in the codebase happen publicly on the [arrow-dev mailing-list](https://lists.apache.org/list.html?dev@arrow.apache.org).
+
+
+## Do you have questions about the source code, the build procedure or the development process?
+
+You can also ask on the mailing-list, see above.
Review comment:
In addition to the arrow-dev mailing list, I think that we can use GitHub issues and/or GitHub discussions (we can enable this by `.asf.yaml`).
@quinnj What do you think about this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] quinnj commented on a change in pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
quinnj commented on a change in pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#discussion_r791911674
##########
File path: CONTRIBUTING.md
##########
@@ -0,0 +1,37 @@
+# How to contribute Apache Arrow Julia
+
+## Did you find a bug or have an improvement?
+
+We recommend you first search among existing [Github issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
+
+
+## How do you write a patch that fixes a bug or brings an improvement?
+If you cannot find the same idea in the issues, you first need to write a GitHub issue (e.g. [issues in Arrow-julia](https://github.com/apache/arrow-julia/issues)) for a bug fix or planned features for the improvement. To write an issue would help the community have visibility and opportunities for collaborations before a pull request (PR) shows up. This is for the [Apache way](http://theapacheway.com/). We can use GitHub labels to identify bugs.
+It should not be necessary to file an issue for some non-code changes, such as CI changes or minor documentation updates such as fixing typos.
+
+After writing the issue, you may want to write a code by creating [a PR](https://github.com/apache/arrow-julia/pulls). In the PR, it is preferable to refer to the issue number (e.g. `#1`) that you already created.
Review comment:
```suggestion
After writing the issue, you can submit code by creating [a PR](https://github.com/apache/arrow-julia/pulls). In the PR, it is preferable to refer to the issue number (e.g. `#1`) that you already created.
```
##########
File path: CONTRIBUTING.md
##########
@@ -0,0 +1,37 @@
+# How to contribute Apache Arrow Julia
+
+## Did you find a bug or have an improvement?
+
+We recommend you first search among existing [Github issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
+
+
+## How do you write a patch that fixes a bug or brings an improvement?
+If you cannot find the same idea in the issues, you first need to write a GitHub issue (e.g. [issues in Arrow-julia](https://github.com/apache/arrow-julia/issues)) for a bug fix or planned features for the improvement. To write an issue would help the community have visibility and opportunities for collaborations before a pull request (PR) shows up. This is for the [Apache way](http://theapacheway.com/). We can use GitHub labels to identify bugs.
+It should not be necessary to file an issue for some non-code changes, such as CI changes or minor documentation updates such as fixing typos.
+
+After writing the issue, you may want to write a code by creating [a PR](https://github.com/apache/arrow-julia/pulls). In the PR, it is preferable to refer to the issue number (e.g. `#1`) that you already created.
+
+
+## Do you want to propose a significant new feature or an important refactoring?
+
+We ask that all discussions about major changes in the codebase happen publicly on the [arrow-dev mailing-list](https://lists.apache.org/list.html?dev@arrow.apache.org).
Review comment:
Yes, the norm in the Julia ecosystem is to use GitHub issues or the new "discussions" feature, which I find both much more easy to digest/follow than mailing list threads. Which reminds me, can we turn on the "Discussions" feature for the arrow-julia repo please? It should just be a checkbox in the repo settings.
##########
File path: CONTRIBUTING.md
##########
@@ -0,0 +1,37 @@
+# How to contribute Apache Arrow Julia
+
+## Did you find a bug or have an improvement?
+
+We recommend you first search among existing [Github issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
+
+
+## How do you write a patch that fixes a bug or brings an improvement?
+If you cannot find the same idea in the issues, you first need to write a GitHub issue (e.g. [issues in Arrow-julia](https://github.com/apache/arrow-julia/issues)) for a bug fix or planned features for the improvement. To write an issue would help the community have visibility and opportunities for collaborations before a pull request (PR) shows up. This is for the [Apache way](http://theapacheway.com/). We can use GitHub labels to identify bugs.
+It should not be necessary to file an issue for some non-code changes, such as CI changes or minor documentation updates such as fixing typos.
+
+After writing the issue, you may want to write a code by creating [a PR](https://github.com/apache/arrow-julia/pulls). In the PR, it is preferable to refer to the issue number (e.g. `#1`) that you already created.
+
+
+## Do you want to propose a significant new feature or an important refactoring?
+
+We ask that all discussions about major changes in the codebase happen publicly on the [arrow-dev mailing-list](https://lists.apache.org/list.html?dev@arrow.apache.org).
+
+
+## Do you have questions about the source code, the build procedure or the development process?
+
+You can also ask on the mailing-list, see above.
Review comment:
Yes, I'd prefer people open issues/discussions than post on the mailing list, personally. I find the repository issue/discussion list to be a good centralized place to refer to open issues/discussions rather than searching through past mailing threads.
##########
File path: CONTRIBUTING.md
##########
@@ -0,0 +1,37 @@
+# How to contribute Apache Arrow Julia
+
+## Did you find a bug or have an improvement?
+
+We recommend you first search among existing [Github issues](https://github.com/apache/arrow-julia/issues). The community may already address the same idea. If you could find the issue, you may want to contribute to the existing issue.
+
+
+## How do you write a patch that fixes a bug or brings an improvement?
+If you cannot find the same idea in the issues, you first need to write a GitHub issue (e.g. [issues in Arrow-julia](https://github.com/apache/arrow-julia/issues)) for a bug fix or planned features for the improvement. To write an issue would help the community have visibility and opportunities for collaborations before a pull request (PR) shows up. This is for the [Apache way](http://theapacheway.com/). We can use GitHub labels to identify bugs.
+It should not be necessary to file an issue for some non-code changes, such as CI changes or minor documentation updates such as fixing typos.
+
+After writing the issue, you may want to write a code by creating [a PR](https://github.com/apache/arrow-julia/pulls). In the PR, it is preferable to refer to the issue number (e.g. `#1`) that you already created.
+
+
+## Do you want to propose a significant new feature or an important refactoring?
+
+We ask that all discussions about major changes in the codebase happen publicly on the [arrow-dev mailing-list](https://lists.apache.org/list.html?dev@arrow.apache.org).
+
+
+## Do you have questions about the source code, the build procedure or the development process?
+
+You can also ask on the mailing-list, see above.
+
+
+## Local Development
+
+When developing on Arrow.jl it is recommended that you run the following to ensure that any changes to ArrowTypes.jl are immediately available to Arrow.jl without requiring a release:
+
+```
+julia --project -e 'using Pkg; Pkg.develop(path="src/ArrowTypes")'
+```
+
+
+## Release cycle
+
+The Julia community would like an independent release cycle. Release for apache/arrow doesn't include the Julia implementation. The Julia implementation uses separated version scheme. (apache/arrow uses 6.0.0 as the next version but the next Julia implementation release doesn't use 6.0.0.)
Review comment:
```suggestion
The Julia community releases independently from the main [apache/arrow](https://github.com/apache/arrow) project. Release for apache/arrow doesn't include the Julia implementation. The Julia implementation uses the more traditional version scheme typical of packages in the Julia ecosystem. The apache/arrow project does regular major version releases, like 6.0.0, whereas apache/arrow-julia will only do major version releases for breaking changes to the user-facing package API.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] kou commented on pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
kou commented on pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#issuecomment-1020820624
1. OK. Thanks for clarifying it.
2. Thanks. I can nominate you as a new committer and then a new PMC member after you work on apache/arrow-julia with the Apache way continuously. See also http://theapacheway.com/ for the Apache way.
For example, preparing `CONTRIBUTING.md` is an important task for it because it helps new contributors to understand how to follow the Apache way. Could you help us complete this pull request? If you help, I can refer this pull request when I nominate you as a committer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] ericphanson commented on pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
ericphanson commented on pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#issuecomment-1019337802
It would be great if this could cover the answer to https://github.com/apache/arrow-julia/pull/267#issuecomment-1019308997 - often when folks contribute a fix or feature they are eager for a release so they can use it downstream.
How it used to work is that after most fixes or features (or on request), Arrow.jl would tag a release. This is done by increasing the version number, and asking the JuliaRegistrator bot to make a PR to the General registry of Julia packages, which would be automatically merged if certain checks passed, which would then write a comment on a “tagbot trigger issue” which would trigger the tagbot workflow to generate a git tag and GitHub release. (This process is somewhat convoluted to guarantee that releases are only made after registration is successful, and is standard in the Julia ecosystem). The only manual step in this process is to kick it off.
This process also requires the JuliaRegistrator bot is installed on this repository. If that is a big problem, one can use the web UI at juliahub.com (which is run by Julia Computing, not the open source community), or registration PRs can be manually (by hand or with the help of LocalRegistry.jl) made to the General registry, which will require manual merging by a registry maintainer (since such PRs won’t be eligible for automerge, at least at this time).
I am not very familiar with Apache’s release process but I am with the Julia ecosystem’s so let me know if anything is unclear or if I can help answer questions or otherwise try to facilitate.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] kou commented on pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
kou commented on pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#issuecomment-1020820624
1. OK. Thanks for clarifying it.
2. Thanks. I can nominate you as a new committer and then a new PMC member after you work on apache/arrow-julia with the Apache way continuously. See also http://theapacheway.com/ for the Apache way.
For example, preparing `CONTRIBUTING.md` is an important task for it because it helps new contributors to understand how to follow the Apache way. Could you help us complete this pull request? If you help, I can refer this pull request when I nominate you as a committer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] quinnj commented on pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
quinnj commented on pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#issuecomment-1021406480
> We need a vote for each new release before we publish a new release. It requires the followings:
>
> 1. We need to create a source package such as `arrow-julia-x.y.z.tar.gz` for each release.
> 2. We need to sign the created source package.
> 3. (If we have binary packages, we also sign binary packages.)
> 4. We need to upload the created source package, (binary packages), sign and checksums to https://dist.apache.org/repos/dist/dev/arrow/ or https://apache.jfrog.io/ui/native/arrow/ for vote.
> 5. We need to at least 3 positive votes (+1) from PMC members (see https://arrow.apache.org/committers/ for the current PMC members) to pass the release vote.
> 6. Release votes SHOULD remain open for at least 72 hours. (This is for accepting votes from all time zones.)
>
> See https://www.apache.org/legal/release-policy.html for details.
I'm going to open a separate issue so we can further discuss the logistics of new releases.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-julia] kou commented on pull request #278: Create CONTRIBUTING.md
Posted by GitBox <gi...@apache.org>.
kou commented on pull request #278:
URL: https://github.com/apache/arrow-julia/pull/278#issuecomment-1019494122
We can use `JuliaRegistries/TagBot` action because it's added to allow list: See #273 and the linked Jira issue for details.
We need a vote for each new release before we publish a new release. It requires the followings:
1. We need to create a source package such as `arrow-julia-x.y.z.tar.gz` for each release.
2. We need to sign the created source package.
3. (If we have binary packages, we also sign binary packages.)
4. We need to upload the created source package, (binary packages), sign and checksums to https://dist.apache.org/repos/dist/dev/arrow/ or https://apache.jfrog.io/ui/native/arrow/ for vote.
5. We need to at least 3 positive votes (+1) from PMC members (see https://arrow.apache.org/committers/ for the current PMC members) to pass the release vote.
6. Release votes SHOULD remain open for at least 72 hours. (This is for accepting votes from all time zones.)
See https://www.apache.org/legal/release-policy.html for details.
Notes:
1. We should prepare verification scripts to verify the release artifacts (source package, binary packages, sign and checksums) for voting by PMC members. e.g. https://github.com/apache/arrow-rs/blob/master/dev/release/verify-release-candidate.sh
2. It's better that Apache Arrow PMC has at least 3 members who work on Apache Arrow Julia for smooth vote in the future.
We can use the standard Julia package release process after a release vote is passed. (We also need to publish passed release artifacts in https://dist.apache.org/repos/dist/dev/arrow/ to https://dist.apache.org/repos/dist/release/arrow/ .)
Here are questions:
1. Do we build binary packages?
2. @ericphanson Are you interested in joining Apache Arrow PMC in the future?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org