[VOTE] Establish TVM Unity Connection Technical Strategy

[tqchen]

Dear community:

This is a formal vote on TVM unity connection technical strategy. We had great discussions and feedback in the discuss thread

Vote:
+1
0 - I don't feel strongly about it, but don't object
-1 - because..

The VOTE will open for a week.

This thread is mirrored to dev@, please vote by replying to this thread

cc @Hzfengsy @junrushao

[YuchenJin]

+1

[tvm-archiver]

+1

…

On Tue, Aug 30, 2022 at 08:05 Yuchen Jin ***@***.***> wrote: +1 -- Reply to this email directly or view it on GitHub: #12651 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[Hzfengsy]

+1

[MasterJH5574]

+1

[vinx13]

+1

[yzh119]

+1

[csullivan]

+1

[sunggg]

+1

[masahi]

+1

[yongwww]

+1

[leandron]

-1 (binding veto)

There is overlap with what is being proposed here being a superset of what is under active discussion in the Relax RFC at apache/tvm-rfcs#89, so I don't think that we can make an informed decision in this RFC, until the discussion in the Relax RFC are settled and we decide on whether it is accepted or not. For that decision to happen, the specific/actionable questions need to be answered.

[tqchen]

Thank you @leandron . As per stated in the beginning, this RFC establishes a strategy to introduce an optional module to TVM, which as of now is minimally disruptive to the current infrastructure.

We also consider it as as a separate RFC from the relax RFC it sets up the overall technical strategies. It also reflects our previous sequence of communications and discussions in the community

I would encourage us to scope the technical reasonings to the scope of the RFC. Note that most of the strategy RFC describes the optional module state. While I fully agree that some of the possible future actions(e.g. change of a default flow) would warrant more in-depth discussions of their own and are helpful to setup a context, they are not necessarily reasons to block the RFC that do not yet propose to make such changes.

This being said, you are more than welcomed to bring technical comments on the discussion thread or RFC as well, so we can continue to discuss concrete items on this RFC. Having clear technical reasonings would help us to move things forward and bring consensus together.

[areusch]

-1 (binding veto)

I agree with @leandron that Establish TVM Unity Connection Technical Strategy RFC is heavily centered around Relax RFC. Additionally, while this RFC stops short of endorsing the Relax RFC as the future direction of TVM, it very explicitly discusses those aspirations. Therefore I do not agree that this RFC is separate from Relax RFC and therefore do not think a VOTE thread is appropriate at this time.

I want to be clear that I am not disagreeing with the technical direction here, but that I don't believe it is yet time to VOTE. I would happily change my vote should more consensus develop in the community.

[tqchen]

Thanks @areusch , the particular section that you described was explicitly listed as "future opportunities" and is not part of the RFC which may or may not be executed. As per stated in the text

"
This section describes possible approaches to evolve the default build to leverage more of unity components. Note again that this is only a discussion of possible approach is not part of the RFC, but only to bring possible relevant context of future opportunities.
The detailed discussions about the exact approach shall happen in dedicated RFCs for each incremental change to the default build.
"

As for endorsing the future. Different users may come with different needs, the primary goal of the RFC is to enable the need for a broad set of users in the community, while not disrupting some of the existing uses. As a community we should aspire to empower all these users and developers, as we can see from the discussions that comes with support from majority of the community for such an optional addition. We do acknowledge that additional followups on default flow should happen in the future in a more informed way, but they should be part of future convos :)