Replies: 1 comment
-
Below are my two cents:
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Currently we don't have commit access to upstream/velox and upstream velox either doesn't have Gluten CI, which leads to our key bug fixes can't be upstreamed in time, and some Velox PRs breaks Gluten's functionality without any check. So we maintain the OAP/Velox to hold the bug fixes which haven't been merged and temporily revert PRs which break Gluten functionality.
What happends in background is that, thanks to Pedro's help, we have the webhook from upstream Velox which is triggered for status change of every upstream Velox PR. So internally in IBM, we have an jenkins pipleline which imports the Velox PR into OAP/Velox once it's merged and run Velox and Gluten CI for every upstream PR. Each day, we create a branch and submit a PR to Gluten to advence the Velox rebase branch.
Recently we forked ibm/velox and will move the process to ibm/velox publicly. We will automatically pick the merged upstream PR and run Velox and Gluten CI. We will fix the bugs on PR conflict or CI failure. We are still building the pipeline, once it passes, we will stop to maintain oap/velox and move to ibm/velox:gluten_main branch. Each day we will create a tag for Gluten to advance the velox rebase. gluten_main branch will only hold the essential features which can make Gluten workable.
Meanwhile, we will pick even more features which haven't been merged into upstream/velox but passed Velox and Gluten CI and mark them advanced features. Once upstream/velox merges the PR, we will move it out from advanced features.
Welcome to share your thought.
Beta Was this translation helpful? Give feedback.
All reactions