Hzfengsy commented on PR #95: URL: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1288633361
@mbaret > TOSA/Linalg are both graph dialects, but they don't fulfill the same function The definition of "same" is subjective; of course, different people can have different opinions that are less grounded. For example, what if many, or even the majority of people think a proposal contains sufficient differences(e.g., in the sense of TOSA/Linalg or TorchScript/TorchFX) that also serve community needs but some don't, does that still count as "same"? The current RFC provides a guideline, considering that "An S0-module should show a clear positive fit to some(but not all) aspects of the project and clear cohesion to some of the existing modules." The "clear positive fit to some" indicates the complementary aspect(that S0-module does something other modules do not do, as a result not the same). Note such evaluation can usually be subjective. We are also not singling out MLIR as a single case here. The TorchScript/TorchFX example serves as a better example in illustrating the situations we are facing here. > The closest example I can think of is [TCP](https://discourse.llvm.org/t/rfc-incubation-request-for-incubating-tcp-dialect-for-mlir/64883) vs. TOSA which was prompted by this lengthy [thread](https://discourse.llvm.org/t/rfc-proposal-for-a-high-level-ml-dialect-in-mlir/64249). However, that caused a huge amount of debate as to whether it was correct to have them both in the repo (similar to what we're seeing with Relax). > > The solution in the LLVM community is to have TCP first exist as an [LLVM incubated project](https://lists.llvm.org/pipermail/llvm-dev/2020-June/142548.html) outside of the mono-repo. To quote the [LLVM developer policy](https://llvm.org/docs/DeveloperPolicy.html#incubating-new-projects) on why they have such a process: Thanks for bringing this up as a reference. Reading through the TCP thread, it is clear that the TCP proposal would not even get majority support from the MLIR core devs (most of the core devs signaled preference of not in-tree devs in that particular thread). An incubation process helps to incubate a module where the majority of the community is still unsure. We do anticipate different fork development methods will be helpful before the S0 stage. We are solving a different problem. Specifically, this process RFC outlines the guideline in situations when the majority agree that in-tree dev is helpful and the discussions of module establishment become subjective. In such cases, considering the scope of impact, users' needs and, more importantly, community empowerment in general. We think the call for the community over code and open-mindedness in the current proposal is appropriate. It also reflects G1 and aligns with the case such as TorchFX starts by offering clear positives to some aspects and continues to offer more aspects to the project. The open-mindedness of PyTorch in allowing modules(such as TorchScript and TorchFX) to co-exist contributes positively to the growth of the PyTorch ML ecosystem. As an ML project in nature and acknowledging G1 and community being critical, this proposal aims to bring that practice formally. One of the last factors is that many of us (considering many who supported the proposal) already were evaluating some of the previous RFCs following the open-mindedness principle already and pushed for community empowerment – which led to some of the RFC acceptance as well as broad inclusion of the community. If we all adopted a stronger subjective opinion and put away consideration of community, many past RFCs would have been rejected or delayed in the subjective debates, including RFCs from those who had stronger subjective opinions. We would hope to continue pushing the community over code principles. While also clarifying the clear transitions and scope of impact. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
