Thank you @leandron . As per stated in the beginning, this RFC establishes a strategy to introduce an optional module to TVM, which as of now is minimally disruptive to the current infrastructure.
We also consider it as as a separate RFC from the relax RFC it sets up the overall technical strategies. It also reflects our previous sequence of [communications](https://tvm.apache.org/2021/12/15/tvm-unity) and [discussions](https://discuss.tvm.apache.org/t/relax-co-designing-high-level-abstraction-towards-tvm-unity/12496) in the community I would encourage us to scope the technical reasonings to the scope of the RFC. Note that most of the strategy RFC describes the optional module state, and possible future opportunities. While I fully agree that some of the possible future actions(e.g. change of a default flow) would warrant more in-depth discussions of their own and are helpful to setup a context, they are not necessarily reasons to block the RFC that do not yet propose to make such changes. This being said, you are more than welcomed to bring technical comments on the [discussion thread](https://discuss.tvm.apache.org/t/establish-tvm-unity-connection-a-technical-strategy/13344) or RFC as well, so we can continue to discuss concrete items on this RFC. Having clear technical reasonings would help us to move things forward and bring consensus together. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/12651#issuecomment-1233048896 You are receiving this because you commented. Message ID: <apache/tvm/issues/12651/1233048...@github.com>
