mbaret commented on PR #95:
URL: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1339463770
> Having a dragging conversation simply due to bundling reduces the ability
for volunteers to participate
I'm sorry but having a 'dragging conversation' is entirely the point of a
RFC. It's not a rubber-stamping process, nor should it be. And this RFC
fundamentally changes the governance model of the project.
> I recommend listening to the majority community's voices and empowering
the community.
Firstly, there aren't many community members even present commenting here,
let alone a majority, so I'm not sure what's meant by this. But more
importantly, and with my Apache hat on, I fundamentally disagree with the
characterisation of those who are not unconditionally supportive of this RFC as
'anti-community'. In my view this is both unnecessarily antagonistic and indeed
wrong.
There are multiple different stakeholders that make up our community, I'll
enumerate 3 types below:
- **Feature developers**
They contribute new capabilities to TVM to ensure it keeps pace with ML
landscape.
- **Maintainers**
They maintain the code to ensure existing capabilities don't regress and
fix bugs when they arise.
- **Users**
They actually apply TVM to real problems so that the project provides
value to the world.
As drafted, S0 modules seek only to empower feature developers at the cost
of maintainers. Users wouldn't even see significant benefits as S0 modules
would necessarily need to be hidden from the majority of users, otherwise
they'd become de facto S1 modules. I therefore consider this proposal, in its
current form, as hostile towards those wishing to contribute towards the
maintenance of TVM.
I would further question whether we have substantial evidence that S0
modules are routinely blocked. We have 3 different auto-tuners, 3 executors, 12
backend targets, 14 BYOC targets and 11 frontends too. The vast majority of
RFCs are approved, as are the vast majority of pull requests. These all point
towards a community that is already extremely accommodating of new features,
perhaps to a fault given our limited capacity to maintain these different
components.
However, the S1 and S2 mechanisms would be of enormous value to maintainers
(and users!) by strictly defining the maintenance surface (S1) and allowing for
that maintenance surface to shrink as well as grow (S2). This would finally
allow us to start reducing the complexity in the code base and aim to provide a
rock-solid user experience where TVM could compete with PyTorch/TensorFlow/ONNX
on robustness.
Could we therefore please stop pretending this RFC 'empowers the majority of
the community' and say what we mean: it empowers the PMC - the composition of
which currently doesn't closely reflect the active contributors in the
community. There's a clear and obvious route to evolving this proposal into
something that benefits everyone via S1/S2 processes, but for an unknown reason
that's being refused.
--
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]
