leandron commented on PR #102:
URL: https://github.com/apache/tvm-rfcs/pull/102#issuecomment-1667516671
> The RFC is about how we operate as a community, and it's not necessarily
related to "gigantic puzzle of features". 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.
>
> As a community of diverse needs, of course, we have different opinions on
how we could drive our technical needs, which is a process issue of any
community operation. If a super majority of the community firmly believe in one
approach of how, I would agree and support it no matter what I personally
believe in. The RFC is just about that the community needs a way to drive
technical resolution.
I wasn't aware of these motivations, I think they should be stated in the
RFC text.
> 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 (and meanwhile, they constantly
bring in coolest new features!). Stability is indeed an important issue to me,
and therefore, if a “stable architecture” already copes with new challenges out
of box, I would personally prefer not to upgrade, just to save my own time.
We are getting confused with the difference between a stable architecture
(components that interact with each other), with API, which is the specific
function calls and classes design to make something work. What I'm arguing is
that we should prioritise evolving our existing components e.g. IRs, rather
than come up with something new every couple years.
Cython and LLVM are great software with mature communities, being used in
many production cases and - I'd argue - very stable.
This is probably one of the reason their contribution guides are clear w.r.t
changes, for example Cython mention the development larger features in branches
before they get into the main codebase
([source](https://github.com/cython/cython/wiki/HackerGuide#feature-branches))
and LLVM has this note in their development guide: **"we need to strike a
balance between being inclusive of new ideas and people and the cost of ongoing
maintenance that new code requires. As such, we have a general support policy
for introducing major new components into the LLVM world, depending on the
degree of detail and responsibility required. Core projects need a higher
degree of scrutiny than peripheral projects, and the latter may have additional
differences."**
So, if said projects keeping control of their architectures break sometimes,
imagine for project that are less careful with that, how would that be?
> Meanwhile, as a PMC member, I would take **PMC 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 grave
concern accordingly on a) community stagnation; b) being out of touch from
major usecases.
I this this paragraph misinterpret the role of the PMC, which is not to
"hear the voice of super majority". It says, instead, among other things: "to
further the long-term development and health of the community as a whole, and
to ensure that balanced and wide scale peer review and collaboration takes
place." ([source](https://www.apache.org/foundation/how-it-works/#pmc)).
I think it is not welcoming and correct to say that there is this "super
majority" that crushes everyone else's opinion. At least this is not the way I
think it should be.
> > 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?
A "subset" is exactly what it is.
> * 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?
Sorry, I'm not aware of statistics in this area. I'm just representing a
view I took from previous numerous discussions around this topic, that I
referred in my previous post.
> 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 text is already off-topic by a lot, so I suggest rather than posting
passive-aggressive questions such as whether long term contributors of this
project agree with "community over code", we focus on clarifying the RFC text,
so that the community understands what is it that we're changing once this goes
to vote.
--
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]
