bkamins commented on issue #342: URL: https://github.com/apache/arrow-julia/issues/342#issuecomment-1272233003
I think, for enterprise adoption, there is value of the fact that Arrow.jl is managed under Apache Arrow umbrella. What I write below assumes Arrow PMC wants to stick to its current rules. So regarding 1. and 2. (PR approval) I think that the practical solution could be: 1. A proposal to add @quinnj to Arrow PMC. 2. Then the process of making PRs would require that someone else that @quinnj makes PRs, and @quinnj reviews them. It would be problematic, but the long-term benefit of this would be that we would have a larger pool of Julia developers that know the internals. Regarding 3. (merging policy) - what @quinnj describes is indeed what is a typical practice in Julia community. However, if Apache PMC wants to keep this rule the good thing is that Julia package manager is flexible enough to work-around this. If user is hit by some bug and it is fixed but not released yet user can install `main` branch temporarily when waiting for a patch release. This is feasible because Arrow has mostly linear development (so it is not e.g. like DataFrames.jl where we usually add loads of new features in `main` and patch releases require a separate branch). Having said that, I think that the starting point for this discussion is a question how Arrow PMC sees the PR approval process given your comments, so that it allows for smooth development while ensuring safety (as this is what I assume Arrow PMC rules are designed around). -- 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]
