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. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/102#issuecomment-1666041650 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/102/c1666041...@github.com>
