编译器深度学习模型优化【免费下载链接】tvmOpen deep learning compiler stack for cpu, gpu and specialized accelerators项目地址https://gitcode.com/gh_mirrors/tvm7/tvm点击查看免费下载本篇技术指南围绕 Apache TVM 开源项目tvm的 Committer 职责展开系统讲解社区优先、公开归档、独立项目管理三大治理原则并逐步拆解引导Shepherd一个 Pull Request 的完整流程、时间管理与广泛协作的实践经验。读者将掌握 TVM 社区中 Committer 的标准工作流从认领 PR、指派审查者、主持评审到达成共识后合入代码并理解背后的 Apache 治理模型与仓库中的 CI 自动化工具是如何支撑这一流程的。文档定位与背景Committer Guide 是 Apache TVM 贡献指南体系中的一份演进中evolving的文档其定位是面向已拥有仓库写权限的 Committer 提供实战建议。文档开篇即说明其中大部分内容来自项目开发过程中的经验教训lessons learned并欢迎每位 Committer 共同补充。整个贡献指南体系还包括社区指南阐述 TVM 采用的 Apache 治理模型、committership 与总体开发流程代码审查指南代码评审的 F0–F4 质量因素与共识构建方法代码规范与技巧C/Python 代码风格与常见实现技巧提交 Pull Request面向贡献者的提交流程与检查清单。本指南可以视为上述文档中角色职责层面的具体操作手册社区指南定义谁是 Committer而本文档回答Committer 应该怎么做。Community First以社区利益为先文档提出的第一原则是Community First社区优先。TVM 依靠集体的力量推进项目因此在做任何决策时都应把社区放在心中。文档给出了三个可以随时自省的问题如何鼓励新贡献者更多地参与项目能否帮助其他 Committer 节省时间是否让社区其他成员能够参与设计提案design proposals这一原则在仓库中有直接体现。CONTRIBUTORS.md 开篇即声明TVM adopts the Apache way and governs by merit并主动邀请earned the merit的贡献者加入开发社区。更具体地说社区指南 将community involvement列为识别潜在 Committer 的三大特质之一活跃参与讨论论坛、通过教程/演讲/外展推广项目并鼓励 Committer 与没有物理接触过的社区成员广泛协作do code reviews and discuss designs with community members that they do not interact physically。Public Archive Principle公开归档原则文档强调虽然私下讨论如面对面交流对开发有用但它会为更广泛社区的参与制造壁垒。Apache 的开发方式要求所有决策在公开渠道进行并且这些渠道需要可归档、人人可访问。这样任何贡献者都能通过查看归档跟上开发进度随时加入讨论。这一原则对 Committer 尤为重要文档给出了两个具体应用场景当有人在私人渠道询问项目相关问题鼓励对方在讨论论坛discuss forum中开一个公开帖让其他社区成员也能从答案中受益在面对面讨论之后向公开渠道发送一份总结可以以 RFC 或讨论帖的形式。TVM 的治理体系正是围绕公开可归档渠道构建的社区指南 明确指出社区鼓励使用 issues、discuss forum 和 mailing-list 等公开、可归档的渠道进行讨论so that everyone in the community can participate and review the process later。重大变更提案RFC也必须在公开渠道发布以供社区讨论。Independent Project Management独立项目管理Apache 治理模型有一条关键假设每个人在参与项目活动时都被视为戴着Apache Committer 帽子。即 Committer 在项目语境下应代表项目的最佳利益行事并严格区分 Committer 身份与其他任何角色。文档特别建议在可能引起混淆的场合主动声明自己戴的是哪顶帽子hat尤其是当自己并未戴着 Committer 帽子时。文档给出了两个示例格式Wearing [foo] hat: [message when serving as foos role and not as committer]戴着 [foo] 角色的帽子而非 Committer 身份发言Wearing Apache TVM hat: [messages when serving as committer]戴着 Apache TVM 的帽子以 Committer 身份发言Shepherd a Pull Request引导一个 PR 的完整流程文档用一组清单式的操作步骤给出了引导shepherdPR 的标准流程这是 Committer 日常工作中最高频的职责。完整的步骤链如下将 PR 指派给自己Assign the PR to yourself让其他 Committer 知道该 PR 已经有人照看避免重复认领使用状态标签status label标明当前状态检查是否需要发送 RFC确认贡献者是否已请求审查者若未请求礼貌地请贡献者自行请求对于新贡献者帮其请求审查者并提醒其下次自行操作主持评审过程Moderate the reviews请审查者明确地 approve将 PR 标记为 accepted并致谢贡献者与审查者合入 PRMerge the PR。关于第 4 步与第 5 步文档进一步指向代码审查指南该指南详细规定了评审过程中的具体做法。引导 PR 背后的自动化支撑仓库中的 CI 工具链为上述流程提供了自动化支撑可以从源码层面印证认领—请求审查—等待—合入的闭环是如何实现的审查者自动识别github_cc_reviewers.py 中的find_reviewers()函数用正则r(cc( [-A-Za-z0-9]))解析 PR 描述中的cc username语法将 提及的社区成员自动添加为 PR 的 Reviewers脚本注释写明 Add cced people in a PR body as reviewers。这正对应文档中帮助贡献者请求审查者的环节——贡献者只需在 PR 描述中写cc reviewer即可完成请求。自动催办机制ping_reviewers.py 通过 GitHub GraphQL API 查询所有处于 OPEN 状态的 PRcheck_pr()函数逐一比较 PR、review、comment 的最新活动时间createdAt/updatedAt/lastEditedAt/publishedAt当time_since_last_action wait_time超过设定的等待时间时会构造一条 ping 消息提醒对应审查者。这对应代码审查指南中Reviewers 应努力对请求了审查的 PR 及时反馈的要求——代码审查指南明确指出Automated tooling helps out in this regard, as PRs with no activity for a set amount of time will get a bot comment pinging the relevant parties.欢迎与引导机器人github_tvmbot.py 中定义了一条对每个新 PR 自动发布的感谢与引导消息THANKS_MESSAGE提示贡献者参考贡献指南并在 PR 线程中请求 [Reviewers] 的代码审查。这正体现了文档第 4 步对于新贡献者帮其请求审查者的社区自动化实践。审查者角色与显式审批社区指南 定义了两类相关角色Committers被授予项目写权限的个人通常负责一个或多个代码领域并监管该领域的代码审查流程Reviewers积极贡献并愿意参与新贡献代码审查的个人由活跃贡献者中识别产生。一个 PR 必须经过至少一位 reviewer 审查才能合入。代码审查指南 进一步明确了显式审批的操作方式当你的评论得到回应后请记住在 PR 的 changes 标签页中点击approve或在代码上评论并选择request changes。若部分 reviewer 在一段时间内如一周未响应且已有审查足够充分代码所有者code owner可以按个案判断是否合入。Time ManagementCommitter 的时间管理Committer 能做的事情很多主持讨论、PR 审查、代码贡献等。做开源项目既有回报也容易让人应接不暇因此文档建议适当的时间管理策略。文档给出的示例做法是一些 Committer 每周设定一个社区日community day在这一天集中处理积压的 PR而其余时间则降低社区关注频率。文档特别强调了一句暖心的提醒你的 merit贡献积累永远不会消失所以在为项目做贡献时请放慢节奏、找到自己的步调。Broad Collaboration广泛协作一个值得注意的倾向是人们往往只与自己认识的人互动。但文档指出广泛的协作是项目成功所必需的。具体到实践层面Committer 应当为平时没有物理接触的社区成员引导 PRshepherd PRs for...community members who you do not interact physically向这些成员请求代码审查request code reviews from...。社区指南 同样强调鼓励 Committer 广泛协作并进一步规定PMCProject Management Committee在提名新成员时应力求提名自己组织之外的候选人PMCs should strive to only nominate new candidates outside of their own organization这是避免项目被单一组织主导的制度性保障。与代码审查及代码规范体系的衔接Committer 引导 PR 时其评审标准由配套文档约束。这三份文档共同构成 TVM 的质量保障体系代码审查的 F0–F4 质量因素代码审查指南 定义了审查代码质量时应考虑的五个因素F0–F4其中架构相关因素被认为最重要因为架构决策最容易积累长期技术债因素关注点F0整体架构公共模块定义、关键数据结构与公共接口F1架构一致性新特性是否与既有架构选择一致、与现有代码良好交互F2代码健壮性与测试覆盖在所有可能的平台/设置下正确运行面向用户的错误要有清晰信息F3用户面 API 文档公共 API 与关键模块接口如include/tvm与用户面 Python API必须有文档F4代码可读性函数命名、整体流程清晰度、复杂逻辑的注释测试覆盖与 API 文档是代码贡献的硬性期望代码可读性相对主观审查者应给出建设性、可执行的评论而不是要求别人完全按自己的方式写代码。共识构建与换位思考代码审查指南 还提出了与 Committer 引导流程直接相关的共识构建Consensus Building原则通过建设性的、基于技术事实的对话保持文明并构建共识拥有该领域所有权的 Committer 可以充当 shepherd综合所有讨论并建议一个可推进的解决方案由于合入merge涉及大量信任shepherd 应在签字前仔细阅读 PR并在合入引发问题时负责跟进合入涉及重大架构变更的 PR 前应等待一段时间例如三天给社区成员表达意见和参与审查的机会。此外还有一致性提醒我们都是人很难做到完美一致。如果贡献者认为准则应用得不一致Committer 应当倾听并坦诚面对——流程与准则需要随社区演进不断迭代。代码规范与合入门槛代码规范与技巧 规定 TVM 采用 Google C/C 风格公共函数用 doxygen 格式文档化Python 代码用 numpydoc 格式并使用python 3.7语言特性。风格由clang-format强制执行可通过 Docker 运行# 用 clang-format 检查某个文件 docker/bash.sh ci_lint clang-format-10 [path-to-file] # 运行全部 lint含 clang-format python tests/scripts/ci.py lint提交 Pull Request 则规定了贡献者侧的要求提交前基于最新main分支 rebasegit fetch upstream git rebase upstream/main、通过 lint 检查等。Committer 在合入前应确认这些门槛均已满足——这些要求与代码审查指南中架构一致性、测试覆盖、API 文档的期望一脉相承。治理层级与角色晋升补充上下文为完整理解 Committer 的职责边界社区指南 补充了治理层级的关键规则战略决策需要 binding votes 的lazy 2/3 多数至少 3 票 1且 1 票数两倍于 -1 票数适用于采用指导级社区战略、建立新模块、采用新代码库或创建新的子项目等重大决策PMC 由活跃 Committer 组成负责主持讨论、管理发布、提名新 Committer/PMC 成员。候选人通常先经 PMC 内部讨论再经共识批准至少 3 个 1 且无否决任何否决必须附带理由。新贡献者成长为 Committer 的路径社区指南 列出的识别特质包括对 RFC、代码审查、新特性提案的持续贡献高质量的、无需大量返工即可合入的代码与良好测试以及论坛等渠道的社区参与。实践清单从零开始担任 Shepherd综合本文档与配套文档一次完整的 PR 引导shepherding会话可以归纳为以下可执行清单认领将 PR assign 给自己打上状态标签审视范围确认 PR 是否聚焦避免多个无关改动合入一个 PR是否需要 RFC是否涉及重大架构变更如是考虑等待约三天再合入确保审查者确认 PR 是否已有 reviewer若是新贡献者帮助其在 PR 描述中以cc username或直接请求 Reviewers 的方式添加审查者主持评审鼓励审查者显式 approve 或 request changes综合各方意见推动共识关注 F0–F4 质量因素确认 lintpython tests/scripts/ci.py lint、测试覆盖与 API 文档达标收尾将 PR 标记为 accepted向贡献者与审查者致谢然后合入复盘若合并后发现回归合入者负责跟进若在评审中总结出可复用的经验可补充到代码规范与技巧中供社区共享。结语Apache TVM 的 Committer 指南虽然篇幅精炼却浓缩了 Apache 开源治理的核心理念公开决策、社区优先、角色分明、广泛协作。而仓库中的 github_cc_reviewers.py、ping_reviewers.py、github_tvmbot.py 等自动化脚本以及 CONTRIBUTORS.md 中按领域标注的 Committer 名录为这套治理原则提供了可运行的工程化支撑——文档描述应该怎么做CI 工具链则让自动做到成为可能。对于任何想深入了解或参与 Apache TVM 社区的开发者从阅读社区指南与代码审查指南开始是进入这一协作体系的最佳起点。赞分享编译器深度学习模型优化【免费下载链接】tvmOpen deep learning compiler stack for cpu, gpu and specialized accelerators项目地址https://gitcode.com/gh_mirrors/tvm7/tvm点击查看免费下载相关推荐Apache TVM Committer 指南社区治理、PR 护航与合入流程全解析Apache TVM Committer 指南社区治理、PR 护航与合入流程全解析 Apache TVM 是采用 Apache 治理模式的机器学习编译器框架模型编译深度学习推理引擎Apache TVM 代码审查指南从质量把关到社区协作的完整实践Apache TVM 代码审查指南从质量把关到社区协作的完整实践 本文是 Apache TVM开源机器学习编译器框架代码审查Code Review实践模型编译深度学习推理引擎Apache MXNet Committer 指南社区优先的协作原则、PR 引领流程与时间管理实践Apache MXNet Committer 指南社区优先的协作原则、PR 引领流程与时间管理实践 本篇指南基于 Apache MXNet 仓库中的 comm深度学习人工智能机器学习分布式训练创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考