Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve process for making changes to both arrow-datafusion and arrow-ballista #2583

Closed
andygrove opened this issue May 21, 2022 · 2 comments
Labels
development-process Related to development process of DataFusion enhancement New feature or request

Comments

@andygrove
Copy link
Member

andygrove commented May 21, 2022

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
As a follow-on to #2582 it would be nice if we could make the process a little easier and more automated.

Describe the solution you'd like
Perhaps we can implement a mechanism where we can say "Depends on ballista branch X" in the PR description and have the scripts pull that version?

Describe alternatives you've considered
Live with the current solution.

Additional context
None

@andygrove andygrove added enhancement New feature or request development-process Related to development process of DataFusion labels May 21, 2022
@tustvold
Copy link
Contributor

tustvold commented May 27, 2022

I've created #2632 to try to improve the workflow for arrow upgrades, as they're every two weeks. That said I feel something is a bit off with this, in my opinion Ballista should follow DataFusion upgrades, not lead them.

The current approach effectively puts the burden of Ballista maintenance onto the DataFusion maintainers, which feels somewhat contrary to the ideals of splitting it out in the first place.

Perhaps in lieu of releasing DataFusion more frequently, we could simply update the git pin within Ballista more frequently. This is what we do with IOx, and often prior to a more risky DataFusion PR we will create a candidate IOx PR to test it out. I think this strikes a pragmatic balance, leaving reviewer discretion as to when to upgrade what.

I think when a non-trivial breaking change is made to DataFusion, it is fair to expect that the contributor will help out with the corresponding changes to Ballista, but I'm not sure mandating the Ballista change is prepared in advance strikes the right balance, especially whilst the APIs of both arrow-rs and DataFusion are so in flux.

I don't know, I would appreciate your thoughts

@andygrove
Copy link
Member Author

I think we can close this now. The current approach seems to be working well enough. Feel free to re-open is I am missing anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development-process Related to development process of DataFusion enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants