junrushao commented on PR #102: URL: https://github.com/apache/tvm-rfcs/pull/102#issuecomment-1666041650
I was a bit confused, and would love to clarify my points first, and ask @leandron to clarify some of your points :-) > It might become too costly for some to keep up with gigantic puzzle of features that are just too complicated to make work. To clarify, according to my read, this RFC is particularly designed to be **extremely conservative** that a decision making should get **super majority (2/3)** of the votes to pass. It means the will of a single person or identity is insufficient to push forward anything unless they convince most of the community members. Intuitively, if a super majority of the community firmly believe in a progress to be made via formal voting, I would agree that this is a technical direction that the community believes in and should invest in. Of course, upon any single commit of any code change, there will be less active contributors feeling left behind, and we do need to care about those contributors even if a super majority think the contrary. Therefore, I would propose to attach a guideline: any legacy code path, if conflicts with a new direction, it has to be preserved in a separate branch. To be clear, there is no case yet that a decision introduces incompatibility against the existing ones, but as PMC members, I should give **sufficient emotional support** to those who could not catch up. > On the flip side, many see value in having a stable architecture with a set of components we can evolve long term in a coherent way, that would require us to be mindful when bringing new alternatives to solutions we already have on the stack I share the same sentiment with you that I wish some of my softwares never got updated, for example, LLVM breaks upon almost every release, and Cython just breaks recently which is a huge headache. Stability is indeed an important issue to me, and therefore, if a “stable architecture” already copes with new technologies out of box, I would personally prefer not to upgrade, just to save my own time. Meanwhile, as a PMC member, I would take responsibility to a) hear the voice of super majority, and b) make concrete progress to keep the software updated to the latest challenge, which further becomes neither my personal will, nor stability concern wishing for zero change or zero break, but a grave concern on a) community stagnation; b) being out of touch from major usecases. > I understand the fact a subset of the community wants to bring changes faster into the TVM stack for the benefit of "a field in fast development" or to attract more contributors, etc. I apologize in advance if I misread as a non-native speaker, but correct me if I was wrong, as a PMC member just like you, I was slightly surprised about your wording on this particular scenario. Given the context that this is an extremely conservative proposal that requires super majority to push forward any technical decision, I would love to have you re-examine the following assumption: - A super majority is described as "a subset of the community". Do you want to clarify if it's you believe super majority is representative in your reasoning? - The motivation of having new features, as you described, is to "attract more contributors" instead of merely coping with latest needs in the field. Do you want to clarify if you believe there is any need to cope with latest needs? To summarize, @leandron, do you agree with me that we value community over code? I'm really grateful to have such a helpful and collaborative super majority of the community, and we concrete deliver for them all the time, making our solution as fast, robust and easy-to-use, solving community problems at large scale. -- 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]
