Apache TVM v0.10.0 Release

[Andrew Luo]

The Apache TVM community is happy to announce the release of TVM v0.10.0.

The TVM community has worked since the v0.10.0 release to deliver many
exciting features and improvements.

   - Metaschedule
  - Software pipelining and padding for irregular shapes for auto
  tensorization
  - Stabilized and polished user-interfaces (e.g. database changes,
  tune_relay)
  - A new MLP-based cost model
   - TIR
  - New schedule primitive for PadEinsum
  - A new TIR node: DeclBuffer
  - INT8 Intrinsics for TensorCores for CUDA!
   - microTVM
  - Improved schedule primitives for ARM v8-m ISA

Check out the release notes on GitHub
 and the source
download here .

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

[Sunghyun Park]

Thank you for sharing your thoughts, @areusch. I think it might be helpful for 
better discussion if you can clarify a little further especially about your 
main concern (2nd one). Particularly, I want to hear more about your thoughts 
on the following things:
1. Are you suggesting the consensus is the right way to go for this optional 
module? If so, I'm wondering how you define the consensus. IMHO, reaching 
unanimous might be practically impossible for the large community like this and 
it does not seem to fit for S0: by definition, S0 is to satisfy clear needs 
from some users in the community, not the entire users. I'm afraid if too high 
bar for optional module may discourage contributors. 
2. This quote below sounds more about the standard process of how we digest a 
giant commit, which could be orthogonal to voting rules. IIUC, this seems like 
the process of integration after the vote of deciding whether community members 
want to accept the proposed optional module or not. Personally, I believe 
voting should be based on the idea or proposal rather than the code size. 
> They might create a giant merge commit, or a 20,000-line commit that isn't 
> reviewed according to the project's standards. Such large changes are often 
> so disruptive to a project as to influence the project's overall direction 
> and, in turn, its community. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1284437870
You are receiving this because you are subscribed to this thread.

Message ID: 

[apache/tvm] [skip ci] Add Janet and Thomas to triagers to help with Issue Triage RFC. (PR #13141)

[Andrew Reusch]

these two volunteered to help triage issues per [Issue Triage 
RFC](https://github.com/apache/tvm-rfcs/blob/main/rfcs/0093_Issue_Triage.md).

@tqchen @driazati 
You can view, comment on, or merge this pull request online at:

  https://github.com/apache/tvm/pull/13141

-- Commit Summary --

  * [skip ci] Add Janet and Thomas to triagers to help with Issue Triage RFC.

-- File Changes --

M .asf.yaml (2)

-- Patch Links --

https://github.com/apache/tvm/pull/13141.patch
https://github.com/apache/tvm/pull/13141.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/13141
You are receiving this because you are subscribed to this thread.

Message ID: 

Re: [apache/tvm] [skip ci] Add Janet and Thomas to triagers to help with Issue Triage RFC. (PR #13141)

[tvm-bot]

Thanks for contributing to TVM! Please refer to the contributing guidelines 
https://tvm.apache.org/docs/contribute/ for useful information and tips. Please 
request code reviews from 
[Reviewers](https://github.com/apache/incubator-tvm/blob/master/CONTRIBUTORS.md#reviewers)
 by @-ing them in a comment.


 * No users to tag found in teams: `skip ci` See 
[#10317](https://github.com/apache/tvm/issues/10317) for 
details

Generated by 
[tvm-bot](https://github.com/apache/tvm/blob/main/ci/README.md#github-actions)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/13141#issuecomment-1284452039
You are receiving this because you are subscribed to this thread.

Message ID: 

Re: [apache/tvm] [skip ci] Add Janet and Thomas to triagers to help with Issue Triage RFC (PR #13141)

[driazati]

Merged #13141 into main.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/13141#event-7625211200
You are receiving this because you are subscribed to this thread.

Message ID: 

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

[Steven S. Lyubomirsky]

I wonder about a situation where some parties indicate up front that they are 
resolutely opposed to ever permitting an S0 module to become S1. Even if this 
process permits the module to be merged as S0, it would essentially be known in 
advance that it is unlikely ever to be fully integrated into the project. Is 
having such a module remain indefinitely in the optional state an acceptable 
outcome? The text of the RFC makes it sound like the S0 state is intended to be 
temporary until the module is either made permanent or deprecated; is that a 
reasonable inference?

In particular, the point about discussing future plans for a module may be 
worth further consideration:
>There should be discussions about how the proposal fits into the project to 
>bring clarity. We also acknowledge that not all S1, S2 level decisions can be 
>made at the beginning. Additionally, an S0-module should show a clear positive 
>fit to some(but not all) aspects of the project and clear cohesion to some of 
>the existing modules. As the development evolves, more discussions will happen 
>in future RFCs with additional evidence that help us to make informed 
>decisions.

If some community members indicate their opposition to an eventual RFC, that 
would render the future roadmap moot, no?

I guess this is a question about having the hard discussion up front or later.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1284610277
You are receiving this because you are subscribed to this thread.

Message ID: 

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

[Andrew Reusch]

 thanks for the replies here, everyone.

@comaniac

>-1 is totally fine and I don't think this Process RFC forbids this. On the 
>other hand, if an RFC is suspensive for a while but we still cannot make every 
>-1 voter happy, it doesn't make sense to me to reject the RFC (we don't 
>actually "reject" it, but prevent it from merging forever is basically the 
>same as reject).

I guess my point here though is: we have this problem for PRs too. We trust 
committers and PMC members not to blockade PRs so long as everyone is 
collaborating. For ordinary RFCs, we have the same situation. We achieve lazy 
consensus through discussion. In cases where there is a disagreement that 
cannot be resolved, and the argument has run its course, I agree it may become 
necessary to relax the requirement of lazy consensus in the name of progress. I 
am not aware of such a case in the project right now. 

To be explicit: in the case of the [Relax 
RFC](https://github.com/apache/tvm-rfcs/pull/89), the authors have not answered 
some key questions that contribute to "discussions about how the proposal fits 
into the project." My understanding is that those answers are coming so the 
argument is not deadlocked.

@sunggg
> Are you suggesting the consensus is the right way to go for this optional 
> module? If so, I'm wondering how you define the consensus. IMHO, reaching 
> unanimous might be practically impossible for the large community like this

Sorry--to clarify my original post, I am suggesting we adopt the same voting 
mechanism as we do for PRs and ordinary RFCs. 

> it does not seem to fit for S0: by definition, S0 is to satisfy clear needs 
> from some users in the community, not the entire users. I'm afraid if too 
> high bar for optional module may discourage contributors.

It seems like 3 PMC approvers is a higher bar for newcomers than merely getting 
a +1 from a committer.

> This quote below sounds more about the standard process of how we digest a 
> giant commit, which could be orthogonal to voting rules.

This was meant to serve as an example of the effect of adopting a resolution 
such as replacing the implementation of a large component or adopting a 
submodule could wind up impacting the project in ways that materially determine 
its future. It is common for projects to fork when two different factions 
cannot reach consensus on a change of this magnitude. In such cases, I could 
see the need to relax the consensus requirement in order to decide which way 
the original project will go.

By contrast, an S0 proposal clearly limits its blast radius and should not 
impact a project to the degree of forking. I don't see a clear reason why we 
cannot use the same voting mechanism we do for PRs and RFCs here.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1285017979
You are receiving this because you are subscribed to this thread.

Message ID: