jrevels commented on issue #284: URL: https://github.com/apache/arrow-julia/issues/284#issuecomment-1041572288
As a similarly "blitz"-y former contributor to Arrow.jl, I wholeheartedly echo @quinnj's sentiments. @kou and the Arrow community have been incredibly welcoming and I truly appreciate their efforts to integrate the Julia package with the overall Apache org. It's clearly a lot of work, and clearly born from an earnest desire to see the community grow and the software improve at a steady clip. However, I do think it was detrimental to the Julia package's health that the core maintainers lost commit access to the Julia package in the transfer to Apache. These former committers had the unique combo of context, skillset, and merit-driven community standing (within the package itself, and in the Julia community at large) to function as core maintainers of the package; stripping them of their access puts the package in an awkward state and goes against the merit-based philosophy that seems to be a shared core between the Julia and Apache communities. > The Julia General registry, builtin Pkg.jl package manager, and ecosystem culture have evolved a pretty high-quality "package maintenance and deployment" infrastructure/process that means the Julia implementation just doesn't benefit as much from the rigorous Apache policies compared to other languages/projects (I can expound on specifics here if people are interested, but in short, many specific Apache release policies are already kind of "builtin" to the standard Julia package release process). 💯 I could not have said it better, and I think this is might be a big driver of the impedance mismatch here. One of the nicest elements of Julia development is how the community's organically-grown package development process achieves such a high degree of ergonomics and robustness simultaneously, both within a given package and across package ecosystems. It lowers the barrier immensely for new contributors without sacrificing quality or iteration time for maintainers, which is (IMO) was a key driver of Julia's early success. It's pretty unfortunate, because I truly believe that close collaboration between the Arrow/Julia worlds could yield really cool capabilities - Julia's JIT/multiple dispatch plus Arrow's memory model constitutes an incredibly fun space to explore from a distributed computing/data engineering perspective. But I agree that if we can't resolve some of the current development pain points in this repository, a fork might make the most sense just to return the codebase to a healthier state so that progress can be made. Further echoing @quinnj, I hope that the cross-community collaboration continues to flourish regardless of the development path we take. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
