Hzfengsy commented on PR #95: URL: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1285347175
Thanks for the input and feedback from the community. Here I'd like to clarify some questions. For @areusch > As the RFC stands now, a committer could simply go and -1 each following PR if they wanted to Note that the reviews of each PR are brought to their own context, and we anticipate grounded constructive actionable comments, such as adding test coverage here/there. The module establishment part can be into subjective discussions that are less grounded, and community empowerment becomes more critical in such cases. An S0 module only has things to do with its scope. We can expect a well-scoped module to benefit from more open-mindedness in evaluating module establishment. S0 modules are not temporal because every module is subject to depreciation with different levels of consideration. We also anticipate that if the S0 module continues to be helpful to the users in its well-scoped fashion, it is totally fine to remain at S0 if changing to S1 is not necessary for the use cases in mind. The change to S1 only has things to do with changes in the scope of impact but not how functional the module is, etc. For @slyubomirsky > some parties indicate up front that they are resolutely opposed to ever permitting an S0 module to become S1 We also like to come back to the fact that it is impossible to cover all aspects in the beginning. e.g., TorchFX, as of now, does not anticipate the usage of TorchDynamo and other cases, and that was the reasoning. We value grounded discussions with technical reasonings. Stating that blank statement upfront is unlikely a welcoming move to the overall community, such a hypothetical statement also does not align with the community over code principle (and blank -1 that is not grounded does not carry weight). Additionally, everyone is supposed to [wear the project hat](https://tvm.apache.org/docs/contribute/committer_guide.html?highlight=committer#independent-project-management). A statement that is based on the interest of a party (and not directly the project), although essential to consider, does not carry binding weight. Having the S0 module evolve provides opportunities for community members to have more grounded cases and help the community collectively work towards goals that would help S1 conversations – while continuing to provide value already through S0-level empowerment. Everyone will evaluate the conversations at the point of S1 proposal and provide grounded discussions. > I guess this is a question about having the hard discussion up front or later. In the OSS project, we all know that it is not possible to get evidence of all perspectives in the very beginning. For example, nobody proposed TorchFX to become the backbone of PyTorch compilation when it was introduced. It is also impossible to have grounded conversations to sort everything out in that first stage. Different decisions are made at different time points with different sets of evidence at that time point. @mbaret > Again I don't think the Torch-MLIR/TOSA example is relevant here, they are different projects under separate governance. Great point. We mistake the TorchMLIR here. There are similar sets of in-tree computational graph dialects that we intended to refer to – both TOSA and Linalg for example are in the MLIR tree and serve as computational graph dialects. > This has been pointed out by others already, but this process does create a risk of modules getting 'stuck' in S0 should they subsequently get blocked on S1 transition (or even stuck in S1 if we can't get consensus for S2). Note that these things happen at different time points and certainly have different considerations. This is also common practice in many ML projects. Take PyTorch as an example, the criteria for accepting TorchFX for example, is certainly much higher than deprecating TorchScript in favor of TorchFX – as of now there is no deprecation of TorchScript but nevertheless FX thrives as part of the core PyTorch compiler. We should also note that we have different sets of evidence at different points due to the nature of developments, and everyone in the community is bound to evaluate this updated evidence accordingly. For example, when TorchFX got started it was not intended for the main torch compilation flow, but as the project evolves and Dynamo is built up, it is now clear that it helps as part of the core PyTorch compiler stack. In short, it is common practice in OSS projects to bring an open perspective to different scopes of impact of a module and evaluate them accordingly. > There are other OSS compiler projects which maintain a high-bar to merge new modules directly (LLVM/MLIR comes to mind) so it'd be good to explain why we're taking an alternative (but still valid) approach. The overall suggestion over S0 is not about lowering the bar to code itself. In that regard, we still come up with the statement of "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." It mainly comes back to the scope of impact and level of open-mindedness when evaluating the related modules. The goal of the RFC process is to clarify that and follow this practice with motivations also outlined in G1 and also empower the community members who clearly voiced their needs for such empowerment. > This is a lower threshold than I've seen in similar projects (which typically adopt majority or 2/3rds majority). Do we have a particular justification for this number? Thank you for bringing this up. 2/3 majority decision normally applies to S1/S2 level decisions that have a bigger scope of impact. This is mainly considering different levels of open-mindedness people normally apply to decisions due to the difference in terms of 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]
