hi Antoine, Thanks for chiming in.
On Mon, Jul 30, 2018 at 4:50 AM, Antoine Pitrou <anto...@python.org> wrote: > > Hi Wes, > > Le 29/07/2018 à 01:44, Wes McKinney a écrit : >> I believe the best way to remedy the situation is to adopt a >> "Community over Code" approach and find a way for the Parquet and >> Arrow C++ development communities to operate out of the same code >> repository, i.e. the apache/arrow git repository. > > I think this is reasonable. I think the only reasonably solution would > be to migrate the Python Parquet bindings to the parquet-cpp repository, > to avoid the circulary dependency (then parquet-cpp would depend on > arrow but not the other way round). But I agree the monorepo approach > would probably produce the least development friction. Moving the Python Parquet bindings would increase our problems because of dependency-hell / ABI issues in the shared libraries shipped with Python releases. Right now things operate fairly smoothly because we ship libparquet.so bundled with pyarrow, though unfortunately this libparquet.so is based on an unreleased version of parquet-cpp (due to bug fixes, ABI / API fixes). To maintain the Python bindings in a separate codebase would mean dealing with with release coordination issues both at the C++ level and the Python level. > > From a community standpoint, I think it all depends whether it's ok to > subsume parquet-cpp development under the Arrow umbrella. Perhaps the > Apache foundation has to give their approval? I don't know how project > governance works. Julian has just replied re: this. From the ASF point of view, the git repositories are merely an implementation detail en route to signed releases created by the project PMCs. As far as who has permission to merge patches, I would be comfortable (with the support of the Arrow PMC) giving commit rights immediately to all Parquet committers who participate actively in parquet-cpp. > >> The only Parquet C++ committer who is not an Arrow committer is Deepak >> Majeti. I think the issue of commit privileges could be resolved >> without too much difficulty or time. > > That's an important data point, thanks. > > Regards > > Antoine.
