tqchen commented on PR #89: URL: https://github.com/apache/tvm-rfcs/pull/89#issuecomment-1336475126
After seeing so many voices in this thread. I think it is important to provide a reply here. I am wearing the Apache TVM hat as a ASF member and Apache TVM PMC member. First of all, I would like to say thank you, everyone, for sharing your voices here. This post has received support from more than eight organizations from both industry and academic backgrounds. Your voices are very important to the community and will not be ignored. As many said, we would love the TVM community to continue being inclusive and innovative while maintaining the stability of existing developed components. I also would like to come out and acknowledge the positions so far: The position that @leandron made so far was: - We do not like to be in a state where relax and relay coexist without deciding the commitment of one replacing another. - As a result, due diligence of such a replacement is mandatory before merging the proposal. I would like explicitly to acknowledge that the above positions have valid rationales, are completely valid, and can be a possible way of software development. I think the position raised by @YuchenJin and others were: - Relax could have the potential to replace relay, but the proposal as it only proposes to have the two modules coexist. - Just like how most OSS projects bring in modules and evolve things (e.g. TorchFX being brought in overlaps with TorchScript, nor plans to immediately phase out TorchScript). The modules can coexist, evolve, and we continue conversations about future co-evolution. - Relax and Relay coexist in the codebase is already a positive step that we shall take, especially considering community empowerment. These are also valid rationales and can be possible ways of developing things. As a first step, I would like to acknowledge each others’ positions as they are valid rationales. The main difference is that there is a disagreement on how we should do things as a community. Such a decision should be made collectively as a community, considering all the factors involved: including code and community factors. We all make our suggestions holding innovation, stability, and community into account. When evaluating a proposal and empowering our community members, we expect every one of us to continue having a constructive conversation, considering the latest context. While the initial comment made by @leandron is valid on its own, I would love to see we re-evaluate our positions message considering all the factors in the latest context, including community empowerment and the collective views of other members. I want to say that by no means do we simply seek to dismiss the original position -- i would apologize if I it makes it feel that way. Instead, we want to acknowledging each view, and we have disagreements on hows, and taking community into consideration. I think we should continue to have constructive conversations in services of many who have voiced their support here. Thank you! -- 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]
