Re: [apache/tvm-rfcs] [Process RFC] Clarify Community Strategy Decision Process (PR #102)

+1 I think this is a substantially improved proposal compared with the similar RFC from last year, being more concise and using a 2/3rds majority which feels appropriate. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/102#issuecomment-1674529045 Yo

Re: [apache/tvm] [VOTE] Clarify Community Strategy Decision Process (Issue #15521)

+1 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/15521#issuecomment-1674502456 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm] [VOTE] Establish TVM Unity Connection Technical Strategy (Issue #12651)

+1 I'd love for us to have more clarity on the future of Relax and Relay, but I don't think vetoing this proposal is now progressing that goal any further. Instead, we're seeing substantial fracturing in the development community, with a number of branches and forks (including production repos)

Re: [apache/tvm-rfcs] [Process RFC] Empowering New Scoped Module to the Project (PR #95)

> First of all, I have updated my last post and please read it through again. Extensively editing your reply after people reply to it creates a discussion that's essentially impossible to follow. If you want to raise new points, and in the interest of maintaining the public record of our discuss

Re: [apache/tvm-rfcs] [Process RFC] Empowering New Scoped Module to the Project (PR #95)

> Imagine a case when a module is being needed by more than eight organizations > -- many of them are industry players, but not all other members. In such a situation, I would expect that with the combined resources of those eight organizations, they could address any concerns raised by the comm

Re: [apache/tvm-rfcs] [Process RFC] Empowering New Scoped Module to the Project (PR #95)

> 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 mode

Re: [apache/tvm-rfcs] [Process RFC] Empowering New Scoped Module to the Project (PR #95)

@Hzfengsy I don't think it's fair or accurate to dismiss legitimate concerns of community contributors as 'subjective'. @areusch has already enumerated in some detail an 'objective' list of impacts that an S0 module can have on the wider project. I think at a minimum we should be addressing th

Re: [apache/tvm-rfcs] [Process RFC] Empowering New Scoped Module to the Project (PR #95)

@yzhliu To clarify, I'm not suggesting we adopt an incubation process for TVM. I'm just explaining that we can't reference MLIR as an example of a community which uses the process described in this RFC, because it in fact uses a completely different process. > In the S0-module proposal, majorit

Re: [apache/tvm-rfcs] [Process RFC] Empowering New Scoped Module to the Project (PR #95)

@Hzfengsy > There are similar sets of in-tree computational graph dialects that we > intended to refer to – both TOSA and Linalg for example are in the MLIR tree > and serve as computational graph dialects. TOSA/Linalg are both graph dialects, but they don't fulfill the same function - TOSA is

Re: [apache/tvm] [VOTE] Commit Messages RFC (Issue #12583)

+1 -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm/issues/12583#issuecomment-1231565146 You are receiving this because you are subscribed to this thread. Message ID:

Re: [apache/tvm-rfcs] Collage RFC (PR #62)

@manupa-arm would be great to get your view on this too -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1069262209 You are receiving this because you are subscribed to this thread. Message ID: