From 8ba03ee9638345562015a7b8796d6a3f50d62841 Mon Sep 17 00:00:00 2001 From: Jack-Khuu Date: Wed, 9 Apr 2025 14:09:40 -0700 Subject: [PATCH] Various typo and 0.6 specific changes to CONTRIBUTING.md --- CONTRIBUTING.md | 50 ++++++++++++++++++++++--------------------------- 1 file changed, 22 insertions(+), 28 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 82076c2727d..7b7fd49b0e9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,15 +1,13 @@ Thank you for your interest in contributing to ExecuTorch! We want to make it easy to contribute to this project. -  - ## Dev Install Set up your environment by following the instructions at -https://pytorch.org/executorch/stable/getting-started-setup.html to clone +https://pytorch.org/executorch/0.6/getting-started-setup.html to clone the repo and install the necessary requirements. -Refer to this [document](https://pytorch.org/executorch/main/using-executorch-building-from-source.html) to build ExecuTorch from source. +Refer to this [document](https://pytorch.org/executorch/0.6/using-executorch-building-from-source.html) to build ExecuTorch from source. ### Dev Setup for Android For Android, please refer to the [Android documentation](docs/source/using-executorch-android.md). @@ -31,7 +29,6 @@ executorch │ ├── cadence - Cadence-specific backends. See doc. │ ├── example - Example backend implementations. │ ├── mediatek - MediaTek-specific backends. See doc. -│ ├── openvino - OpenVINO backend for Intel hardware. │ ├── qualcomm - Qualcomm-specific backends. See doc. │ ├── transforms - Transformations for backend optimization. │ ├── vulkan - Vulkan backend for cross-platform GPU support. See doc. @@ -41,12 +38,12 @@ executorch ├── devtools - Model profiling, debugging, and inspection. Please refer to the tools documentation for more information. │ ├── bundled_program - a tool for validating ExecuTorch model. See doc. │ ├── etdump - ETDump - a format for saving profiling and debugging data from runtime. See doc. -│ ├── etrecord - ETRecord - AOT debug artifact for ExecuTorch. See doc. -│ ├── inspector - Python API to inspect ETDump and ETRecord. See doc. +│ ├── etrecord - ETRecord - AOT debug artifact for ExecuTorch. See doc. +│ ├── inspector - Python API to inspect ETDump and ETRecord. See doc. │ └── visualization - Visualization tools for representing model structure and performance metrics. ├── docs - Static docs tooling and documentation source files. ├── examples - Examples of various user flows, such as model export, delegates, and runtime execution. -├── exir - Ahead-of-time library: model capture and lowering APIs. EXport Intermediate Representation (EXIR) is a format for representing the result of torch.export. This directory contains utilities and passes for lowering the EXIR graphs into different dialects and eventually suitable to run on target hardware. +├── exir - Ahead-of-time library: model capture and lowering APIs. EXport Intermediate Representation (EXIR) is a format for representing the result of torch.export. This directory contains utilities and passes for lowering the EXIR graphs into different dialects and eventually suitable to run on target hardware. │ ├── _serialize - Serialize final export artifact. │ ├── backend - Backend delegate ahead of time APIs. │ ├── capture - Program capture. @@ -58,7 +55,7 @@ executorch │ ├── serde - Graph module serialization/deserialization. │ ├── verification - IR verification. ├── extension - Extensions built on top of the runtime. -│ ├── android - ExecuTorch wrappers for Android apps. Please refer to the Android documentation and Javadoc for more information. +│ ├── android - ExecuTorch wrappers for Android apps. Please refer to the Android documentation and Javadoc for more information. │ ├── apple - ExecuTorch wrappers for iOS apps. Please refer to the iOS documentation and how to integrate into Apple platform for more information. │ ├── aten_util - Converts to and from PyTorch ATen types. │ ├── data_loader - 1st party data loader implementations. @@ -69,7 +66,7 @@ executorch │ ├── memory_allocator - 1st party memory allocator implementations. │ ├── module - A simplified C++ wrapper for the runtime. An abstraction that deserializes and executes an ExecuTorch artifact (.pte file). Refer to the module documentation for more information. │ ├── parallel - C++ threadpool integration. -│ ├── pybindings - Python API for executorch runtime. This is powering up the runtime Python API for ExecuTorch. +│ ├── pybindings - Python API for executorch runtime. This is powering up the runtime Python API for ExecuTorch. │ ├── pytree - C++ and Python flattening and unflattening lib for pytrees. │ ├── runner_util - Helpers for writing C++ PTE-execution tools. │ ├── tensor - Tensor maker and TensorPtr, details in this documentation. For how to use TensorPtr and Module, please refer to the "Using ExecuTorch with C++" doc. @@ -86,12 +83,12 @@ executorch ├── runtime - Core C++ runtime. These components are used to execute the ExecuTorch program. Please refer to the runtime documentation for more information. │ ├── backend - Backend delegate runtime APIs. │ ├── core - Core structures used across all levels of the runtime. Basic components such as Tensor, EValue, Error and Result etc. -│ ├── executor - Model loading, initialization, and execution. Runtime components that execute the ExecuTorch program, such as Program, Method. Refer to the runtime API documentation for more information. +│ ├── executor - Model loading, initialization, and execution. Runtime components that execute the ExecuTorch program, such as Program, Method. Refer to the runtime API documentation for more information. │ ├── kernel - Kernel registration and management. │ └── platform - Layer between architecture specific code and portable C++. ├── schema - ExecuTorch PTE file format flatbuffer schemas. ├── scripts - Utility scripts for building libs, size management, dependency management, etc. -├── shim - Compatibility layer between OSS and Internal builds. +├── shim_et - Compatibility layer between OSS and Internal builds. ├── test - Broad scoped end-to-end tests. ├── third-party - Third-party dependencies. ├── tools - Tools for building ExecuTorch from source, for different built tools (CMake, Buck). @@ -106,8 +103,8 @@ We actively welcome your pull requests (PRs). 1. [Claim an issue](#claiming-issues), if present, before starting work. If an issue doesn't cover the work you plan to do, consider creating one to provide context about it, and to build consensus about the scope and solution. -1. Create your new branch from `main` in your forked repo, with a name - describing the work you're completing; e.g., `add-feature-x`. +1. Create your new branch from `0.6` in your forked repo, with a name + describing the work you're completing; e.g. `add-feature-x`. 1. If you've added code that should be tested, add tests. Ensure all tests pass. See the [testing section](#testing) for more information. 1. If you've changed APIs or added a new tool or feature, [update the @@ -192,9 +189,6 @@ in the Github repo. ## Coding Style -Goal: Encourage standards that make it easier to read, edit, maintain, and debug -the ExecuTorch code. - ### lintrunner We use [`lintrunner`](https://pypi.org/project/lintrunner/) to help make sure the @@ -259,7 +253,7 @@ toolchains, and having access to relatively modern C++ features. #### C/C++ standard library usage -**Restricted usage of the C++ standard library.** +**Restricted usage of the C++ standard library** Rationale: ExecuTorch is intended to be portable to bare-metal systems that lack certain features, like dynamic memory, threading, and locking, required by parts @@ -280,7 +274,7 @@ careful to also manually destroy objects initialized in this way. #### C++ language features -**Exceptions: Do not use.** +**Exceptions: Do not use** - Rationale: Exceptions are not widely supported on some classes of microcontrollers and DSPs, and they can significantly increase binary size. @@ -289,12 +283,12 @@ must work with threading** - Rationale: The core runtime must work on systems that do not have threading support. -**RTTI, dynamic_cast, and ``: Do not use.** +**RTTI, dynamic_cast, and ``: Do not use** - Rationale: RTTI adds extra data to every virtual class. ExecuTorch doesn't have a strong need for `dynamic_cast` and friends, so it's better to reduce the binary size. -**Templates and template metaprogramming: Be careful and avoid if possible.** +**Templates and template metaprogramming: Be careful and avoid if possible** - Rationale: Most templating results in code generation, and is one of the most common sources of binary bloat. Some use of templates is fine (e.g. an `ArrayRef`, or code that handles multiple `ScalarType` types), but for the @@ -327,8 +321,8 @@ the code you're modifying and find an author who has more context. Ask them for their help in the PR comments. ### Continuous Integration -See https://hud.pytorch.org/hud/pytorch/executorch/main for the current state of -the CI (continuous integration) jobs. If `main` is broken, consider rebasing +See https://hud.pytorch.org/hud/pytorch/executorch/0.6 for the current state of +the CI (continuous integration) jobs. If `0.6` is broken, consider rebasing your PR onto the `viable/strict` branch, which points to the most recent all-green commit. @@ -354,14 +348,14 @@ website preview based on your changes. ## Pull Requests This repo uses Github pull requests (PRs) to stage and review code before -merging it into the `main` branch. See the [Github +merging it into the `0.6` branch. See the [Github docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) for basics. 1. Push your branch to your fork of `pytorch/executorch`. Most people do not - have permission to push a branch directoy to the upstream repo. + have permission to push a branch directory to the upstream repo. 1. Create your PR - - Use the `main` branch as the base. + - Use the `0.6` branch as the base. - Give the PR a clear and descriptive title. It will become the title of the merged commit, so it needs to be useful in the output of `git log`. - Bad title: "Fix a bug" @@ -409,7 +403,7 @@ for basics. reviewers. A member of the ExecuTorch repo will find someone to review it. 1. Address and discuss comments left by reviewers - If the reviewers have requests or questions, follow up with them. - - The goal of the reviewer is to ensure that the code in the `main` branch of + - The goal of the reviewer is to ensure that the code in the `0.6` branch of the repo is consistent, maintainable, and of high quality. 1. Once the PR has been approved, - If you have the "write permission" in this repo, you can merge it yourself @@ -420,7 +414,7 @@ for basics. to validate it against internal CI. - If the PR is approved but not merged within 5 business days, please comment on the PR to ask about its status. - - Note that if the `main` [CI](#continuous-integration) jobs are broken, we + - Note that if the `0.6` [CI](#continuous-integration) jobs are broken, we will only merge PRs that fix the broken jobs until all critical jobs are fixed.