Philipp Moritz created ARROW-2954:
-
Summary: [Plasma] Store object_id only once in object table
Key: ARROW-2954
URL: https://issues.apache.org/jira/browse/ARROW-2954
Project: Apache Arrow
Philipp Moritz created ARROW-2953:
-
Summary: [Plasma] Store memory usage
Key: ARROW-2953
URL: https://issues.apache.org/jira/browse/ARROW-2953
Project: Apache Arrow
Issue Type: Improvement
hi,
On Tue, Jul 31, 2018 at 4:56 PM, Deepak Majeti wrote:
> I think the circular dependency can be broken if we build a new library for
> the platform code. This will also make it easy for other projects such as
> ORC to use it.
> I also remember your proposal a while ago of having a separate
> The current Arrow adaptor code for parquet should live in the arrow repo.
> That will remove a majority of the dependency issues. Joshua's work would not
> have been blocked in parquet-cpp if that adapter was in the arrow repo. This
> will be similar to the ORC adaptor.
This has been
A controlled fork doesn’t sound like a terrible option. Copy the code from
parquet into arrow, and for a limited period of time it would be the primary.
When that period is over, the code in parquet becomes the primary.
During the period during which arrow has the primary, the parquet release
Wes,
Unfortunately, I cannot show you any practical fact-based problems of a
non-existent Arrow-Parquet mono-repo.
Bringing in related Apache community experiences are more meaningful than
how mono-repos work at Google and other big organizations.
We solely depend on volunteers and cannot hire
Wes McKinney created ARROW-2952:
---
Summary: [C++] Dockerfile for running include-what-you-use checks
Key: ARROW-2952
URL: https://issues.apache.org/jira/browse/ARROW-2952
Project: Apache Arrow
Wes McKinney created ARROW-2951:
---
Summary: [CI] Changes in format/ should cause Appveyor builds to
run
Key: ARROW-2951
URL: https://issues.apache.org/jira/browse/ARROW-2951
Project: Apache Arrow
@Antoine
> By the way, one concern with the monorepo approach: it would slightly
> increase Arrow CI times (which are already too large).
A typical CI run in Arrow is taking about 45 minutes:
https://travis-ci.org/apache/arrow/builds/410119750
Parquet run takes about 28
Antoine Pitrou created ARROW-2950:
-
Summary: [C++] Clean up util/bit-util.h
Key: ARROW-2950
URL: https://issues.apache.org/jira/browse/ARROW-2950
Project: Apache Arrow
Issue Type: Task
Wes McKinney created ARROW-2949:
---
Summary: [CI] repo.continuum.io can be flaky in builds
Key: ARROW-2949
URL: https://issues.apache.org/jira/browse/ARROW-2949
Project: Apache Arrow
Issue Type:
Krisztian Szucs created ARROW-2948:
--
Summary: [Packaging] Generate changelog with crossbow
Key: ARROW-2948
URL: https://issues.apache.org/jira/browse/ARROW-2948
Project: Apache Arrow
Issue
hi Renato,
Sounds like a useful feature to have (to be able to inspect data page
metadata without decoding all the data inside). You'll need to propose
a change and patch to Apache Parquet
Speaking of which, we're having a discussion on the Arrow and Parquet
mailing lists about easing
Kouhei Sutou created ARROW-2947:
---
Summary: [Packaging] Remove Ubuntu Artful
Key: ARROW-2947
URL: https://issues.apache.org/jira/browse/ARROW-2947
Project: Apache Arrow
Issue Type: Improvement
Kouhei Sutou created ARROW-2946:
---
Summary: [Packaging] Stop to use PWD in debian/rules
Key: ARROW-2946
URL: https://issues.apache.org/jira/browse/ARROW-2946
Project: Apache Arrow
Issue Type:
Kouhei Sutou created ARROW-2945:
---
Summary: [Packaging] Update argument check for 02-source.sh
Key: ARROW-2945
URL: https://issues.apache.org/jira/browse/ARROW-2945
Project: Apache Arrow
Issue
16 matches
Mail list logo
