[VL] maintaince of Velox and enhanced features

[FelixYBW]

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.

[weiting-chen]

Below are my two cents:

1. Moving the Velox repository could have a significant impact. It might be a good idea to initiate a vote on the mailing list to gather community consensus.
2. The original plan was to minimize the gap between oap/velox and upstream Velox, with the long-term goal of eventually aligning fully with the upstream version.
3. My main concern is around the governance of the ibm/velox repository. Transferring the repository to a private company may not be ideal for an open-source project. If such a move is necessary, we should consider hosting it under a neutral third-party organization to ensure transparency and community trust.