Hi all, as suggested in the thread, we held this thread for a while. And now it can be a good time to come back.
Let me summarize the previous discussion here: - Scoped module A scoped module (S0-module) can be: > - Clearly isolated in its own namespace. > - Clearly needed by some users in the community. > - No disruptive change to the rest of the codebase > - Can be easily deprecated by removing the related namespaces > - Can be turned off through a feature toggle to contain the overall dependency from the rest of the modules. - voting mechanism Establishing a scoped module is not a typical code change, which needs to get majority support from PMC. This kind of voting mechanism is also used in other Apache Projects (e.g., [Apache Hadoop process](https://hadoop.apache.org/bylaws.html) and [Apache Hive Bylaws](https://cwiki.apache.org/confluence/display/Hive//Bylaws) - The community should evaluate the scoped module with a variety of factors, wearing the project hat: > - Fit into the overall project and rest of the modules and project. > - Test strategy, modularization, and documentation. > - The scope of impact of the added module, and levels of open-mindedness. > - Competitive landscape of the overall MLC space and enablement of the project towards goals that are not supported atm. > - Community empowerment in general: e.g. contributors who would become an added force of offset development complexity, and also in a lot of cases contribute to other existing modules. - Scoped module does not mean to be a low-quality module. All code changes for scoped modules are in the same code review mechanism Please let me know if I miss any public voice and considerations. And let's continue on discussion and finalize the RFC. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1336400761 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/95/c1336400...@github.com>
