Thanks everyone for discussions so far. There are a lot of conversations around the clarifications and issues being answered. Two of the main concern being raised so far seems to be:
- rationales and alternatives. - overall scope and execution In this case, @YuchenJin have: - Updated the RFC with the [rationales and alternatives](https://github.com/YuchenJin/tvm-rfcs/blob/relax-upstream-rfc/rfcs/0089-relax-upstreaming.md#6-rationale-and-alternatives) - Clarified that the scope of the proposal being in scoped to checking in the module as optional and non-disruptive or changing existing modules. I think the above two actions have addressed the concerns being raised wrt to the particular scope of this RFC. @leandron @ekalda @Mousius please followup and see if you have more questions Let us continue follow the overall guideline of providing grounded technical justifications and bring constructive discussions, knowing that some of the high-level tastes argument can be subjective. In those cases, thinking about the **community over code** principle can go a long way. The particular Unity connection strategy already got majority support from the community(from more than 8 organizations), let us think about how can we collectively empower those members together. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/89#issuecomment-1265878050 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/89/c1265878...@github.com>
