Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/apache/tvm-rfcs

A home for the final text of all TVM RFCs.
https://github.com/apache/tvm-rfcs

hardware machine-learning tensor tvm vta

Last synced: 11 months ago
JSON representation

A home for the final text of all TVM RFCs.

Awesome Lists containing this project

README 

          



# Apache TVM RFCs



## Table of Contents

[Table of Contents]: #table-of-contents



  - [Table of Contents]

  - [What is an RFC]

  - [RFC Audience]

  - [RFC Workflow]

  - [References]

  - [About TVM]

  - [License]

  - [Contribute to TVM]



## What is an RFC?

[What is an RFC]: #what-is-an-rfc



An RFC is a “Request for Change” to the TVM project. It is a design document

that describes a new feature, enhancement, or process to the TVM project. RFCs

should be the primary mechanism for proposing major features and changes. The

author of the RFC is responsible for the discussion of the change, and for

organizing the work around it. RFCs are text files, stored in the [Apache TVM

RFC repository](https://github.com/apache/tvm-rfcs), that serve as history and

documentation of TVM features.



## RFC Audience

[RFC Audience]: #rfc-audience



The primary audience of RFCs is the TVM development community. RFCs serve as a

guide for the design and implementation of features during and after their

development. A secondary audience is general users and developers who are

interested in how and why a feature was designed and implemented.



## RFC Workflow

[RFC Workflow]: #rfc-workflow



To work on a major feature within the TVM project, an RFC must first be merged

into the TVM RFC repository as a markdown file. Once merged, the RFC is

considered to be "active" and may be implemented, with the goal of merging the

implementation into the TVM project. These are steps that should be taken in

the RFC process:



- **Community Discussion**: A need or issue is brought to the

  [discussion forum](https://discuss.tvm.apache.org). During this phase, the

  developer and user community can discuss the need for and requirements of the

  RFC.

- **Pull Request**: After or concurrent with the conversation on the discussion

  forum, a pull request is created using the format prescreibed by the

  [RFC Template](https://github.com/apache/tvm-rfcs/blob/main/0000-template.md)

    - Discussion about the details of the RFC can continue in the pull request.

	- A committer of the corresponding area will approve and merge the RFC.

      Normally the corresponding committer will become the shepherd of the

      implementation PRs.

	- RFCs are numbered according to the PR number assigned by GitHub in the

      `tvm-rfcs` repository. To allocate a new RFC number, open a PR against

      `tvm-rfcs` (initially, you might need to use a dummy number in the filename

      for the RFC content; this can be updated after the RFC PR is created).

    - Legacy RFCs are those RFCs which were accepted prior to forming the tvm-rfcs

      repo. These will be numbered consecutively, prefixed with the letter `L` to

      indicate it is a legacy RFC. For example, `L0001`.

	- A successful RFC will include an overview with the problem the RFC is

      attempting to address, a proposed solution that describes the design and

      implementation strategy, and a timeline for completion. Optional sections can

      include (but are not limited to) alternatives that were considered, security

      considerations, and open problems that the RFC does not solve.

	- It is expected that RFCs will change, as part of the feedback process and

      as new implementation details arise. In order to retain change and discussion

      history, changes to the RFC should not be squashed or force pushed.

    - The formal RFC may link back to the original discussion if there is

      additional context or discussion, but all of the final feature design

      must be completely described in the pull request.

- **Tracking Issue**: When the RFC review is about to merge, a committer

  should remind authors to open a tracking issue in the main TVM repository with the

  title "[RFC][Tracking][] " and *rfc-tracking* label

  (added by a committer), where implementors can continue sharing

  implementation details (including links to pull requests). The issue will be

  closed when the RFC is either completed or postponed.

- **Implementation**: Work will begin on the RFC, with pull requests linking

  back to the tracking issue.  Upon completion of the RFC, the tracking issue

  will be closed with the tag "completed". It is not a requirement for the

  author of an RFC to implement it. The tracking issue will serve as the

  primary location for communication about the status of RFC implementation. If

  you are curious about who is working on an RFC, feel free to ask on the

  comment on the associated issue.

- **Changes**: It is not uncommon for design changes to be required during or

  after the initial implementation. If this is the case, the RFC should be

  updated to reflect the change. In the instance where the change is a

  significant addition rather than a simple modification, a new RFC should be

  posted with appropriate tracking issue.

- **Postponement**: An RFC may be postponed either explicitly by the parties

  responsible for implementing it, or implicitly by having no work done for a

  period of time defined by project leaders. The tracking issue for the RFC

  will be closed with the tag "postponed".

    - **Resuming an Postponed RFC**: Work on a postponed RFC may be resumed by

      a new responsible party at any time after appropriate discussion in the

      tracking issue. The issue will be reopened, and the "postponed" tag

      removed.



## References

[References]: #references



[RFC Discussion Post](https://discuss.tvm.apache.org/t/rfc-update-rfc-process/9033)



# About TVM

[About TVM]: #about-tvm



Apache TVM is a compiler stack for deep learning systems. It is designed to

close the gap between the productivity-focused deep learning frameworks, and

the performance- and efficiency-focused hardware backends. TVM works with deep

learning frameworks to provide end to end compilation to different backends.



## License

[License]: #license

© Contributors Licensed under an [Apache-2.0](LICENSE) license.



## Contribute to TVM

[Contribute to TVM]: #contribute-to-tvm

TVM adopts Apache committer model. We aim to create an open source project that

is maintained and owned by the community. Check out the

[Contributor Guide](https://tvm.apache.org/docs/contribute/).