Philipp Moritz created ARROW-954:
Summary: Make it possible to compile Arrow with header-only boost
Key: ARROW-954
URL: https://issues.apache.org/jira/browse/ARROW-954
Project: Apache Arrow
I
Wes McKinney created ARROW-953:
--
Summary: Use cmake / curl from conda-forge in CI builds
Key: ARROW-953
URL: https://issues.apache.org/jira/browse/ARROW-953
Project: Apache Arrow
Issue Type: Imp
hi folks,
The Arrow implementations are built generally with a similar layering of
tools:
* Buffer objects supporting reference counting and zero-copy slicing
* Type metadata
* Vector/Array containers, and Record Batch containers
* IO interfaces for handling stream-like objects, files, memory-map
hi folks,
With 3 binding +1 votes, 2 non-binding +1 votes, and no +0 or -1 votes, the
vote passes.
Since it's Friday afternoon on the East Coast, I will wait until Monday
morning to send the release announcements and update the website. In the
meantime, we need to:
* Upload source artifacts to S
Philipp Moritz created ARROW-952:
Summary: Compilation error with clang-802.0.42
Key: ARROW-952
URL: https://issues.apache.org/jira/browse/ARROW-952
Project: Apache Arrow
Issue Type: Bug
Brian Hulette created ARROW-951:
---
Summary: [JS] Add generated API documentation
Key: ARROW-951
URL: https://issues.apache.org/jira/browse/ARROW-951
Project: Apache Arrow
Issue Type: Task
Wes McKinney created ARROW-950:
--
Summary: [Site] Add Google Analytics tag
Key: ARROW-950
URL: https://issues.apache.org/jira/browse/ARROW-950
Project: Apache Arrow
Issue Type: Improvement
> There could be situations where we don't
> want to include all commits in the next release candidate when a vote fails
Absolutely agree. So, to adhere to Apache's policy of not rewriting
master, you should make the release from a branch, but lock master so
that you can fast-forward merge onto ma
I've never been a fan of the Calcite process where there is a strong desire
to keep the release commit in the master branch & locking the branch.
I prefer branching when we want to start a release. The branch can always
be cherry-picked to/from as necessary and/or re-forked as necessary. When
the
I'm OK with rebasing master after releases for the next couple releases,
and we'll see how it goes (though I had always thought force pushing
upstream master was a faux pas). There could be situations where we don't
want to include all commits in the next release candidate when a vote fails:
rcX
c
I’m fine with either proposal (holding off commits during the release vote, or
rebasing master afterwards).
I agree with Julien that it’s really nice to have a simple, linear history
(with releases on the master branch) and since Arrow is a fairly low-volume
project we’re lucky we can do that.
Alternatively we can rebase master on the release if patch have been merged
concurently to the release vote.
I think it is fine to rebase commits that have not been released yet.
(the release sha however must stay the same)
I find usefull to have the release tag in the master history to know byt
lo
Brian Hulette created ARROW-949:
---
Summary: [JS] Use flatc to generate TypeScript
Key: ARROW-949
URL: https://issues.apache.org/jira/browse/ARROW-949
Project: Apache Arrow
Issue Type: Bug
Kouhei Sutou created ARROW-948:
--
Summary: [GLib] Update C++ header file list
Key: ARROW-948
URL: https://issues.apache.org/jira/browse/ARROW-948
Project: Apache Arrow
Issue Type: Bug
C
For the first few releases, we've been holding off merging patches to
master while the release vote is in progress, partially because of the
commits that the maven-release-plugin commits.
I would propose that in the future we continue to merge patches and perform
the release tag in a branch (so th
15 matches
Mail list logo
