Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

简介

感谢您有意为 FreeRTOS 项目贡献自己的一份力量。无论是漏洞报告、 新功能、更正还是其他文档，我们都非常重视社区的反馈和 贡献。在提交问题或拉取请求之前，请阅读拉取请求流程，确保 您已提供所有必要信息，方便我们有效回应您的漏洞报告或贡献。

拉取请求流程

本节介绍将拉取请求 (PR) 提交到 GitHub FreeRTOS 组织的 GitHub 存储库所经历的各个阶段。在开始 PR 之前，请阅读并熟悉 《贡献指南》。

术语

FreeRTOS 合作伙伴贡献者
这些是来自社区的精选开发者和专家。

FreeRTOS 团队
FreeRTOS 团队由 AWS 员工组成。

代码所有者
对于所有 FreeRTOS 存储库而言，“FreeRTOS 团队”和/或“FreeRTOS 合作伙伴贡献者”都属于代码所有者。

贡献者
提交拉取请求的人员。

受理人
负责确定审核者和管理 PR 的 AWS 员工。该员工会跟踪 PR 的进度， 并确保及时审核和合并 PR。

审核者
负责审核 PR 并向贡献者提供反馈的人员。如需合并 PR， 需要两次审批，其中一次必须由存储库的代码所有者审批。

拉取请求生命周期

提交后的 PR 将经历以下阶段：

  1. 打开

    1. 创建 PR。
    2. 所有 GitHub Actions 均已通过，PR 准备接受审核。

  2. 分类

    1. 将 PR 分配给受理人。
    2. 受理人从 FreeRTOS 团队指派一位审核者来处理 PR。

  3. 初次审核

    1. 审核者提供反馈并在需要时与贡献者讨论未决问题。
    2. 如果贡献者和审核者经过讨论后得出结论认为该 PR 不会被合并，则关闭该 PR。
    3. PR 贡献者处理反馈并根据需要对 PR 进行更改。
    4. 审核者批准 PR 并指派第二位审核者。

  4. 二次审核

    1. 第二位审核者审核 PR，并在需要时提供反馈。
    2. PR 贡献者处理反馈并根据需要对 PR 进行更改。
    3. 第二位审核者批准 PR。

  5. 测试

    1. 其中一位审核者测试 PR，确保其正常运行。

  6. 准备合并

    1. 在满足所有分支保护规则后， PR 的状态将变为“准备合并”。分支保护规则 要求如下：
    2. 至少经过两次审核。
    3. 其中一次由相关存储库的代码所有者审核。
    4. 必须通过所有 PR 检查。

  7. 合并

    1. 合并 PR。

PR 的状态通过审核者和受理人添加的 GitHub 标签来指示。以下 是最常见的状态指示标签：已分类、已指派审核者、概念肯定确认/否定确认、首次代码审核 进行中、首次代码审核完成、第二次代码审核进行中、第二次代码审核完成、 测试进行中以及测试完成。

请注意，我们可能决定跳过某些阶段，具体取决于 PR 的类型，例如， 简单文档更新 PR 可能不会经历上述所有阶段，但是所有 PR 都需要 获得两位审核者的批准。

我们的 PR 流程图示如下。

PR 流程图示

周转时间

审核 PR 所需的时长无法预测。不同 PR 的审核时长不同，具体取决于 更改的复杂程度、审核者是否有空以及团队的整体工作量。我们通常 会尽量在下列时间段（周末和公共假日除外）内完成 PR 的处理：

  • 分类： 24 小时内
  • 概念肯定确认/否定确认：1-2 周
  • 代码审核：1-2 周
  • 测试：1-2周

处理审核者要求的更改

作者应在 4 周或更短时间内处理审核意见。如果作者无法 在上述时间内处理审核意见，我们将采取以下措施：

  • 自行完成必要的更改并合并拉取请求。
  • 关闭拉取请求。

加快审核的最佳做法

遵循以下最佳做法有助于让您的 PR 快速得到审核。

  • 如果您计划向 FreeRTOS 提供新功能，请事先确认 FreeRTOS 团队和社区是否想要并愿意接受此功能。您计划提出大规模更改或重大更改时， 尤其应该如此。如需获得 FreeRTOS 团队和社区的确认和反馈， 请在 FreeRTOS 论坛中发布帖子。

  • PR 越小越好。有针对性的小型 PR 将得到更快、更全面的审核，更方便回退， 被拒时浪费的精力更少。避免提交涉及多个概念的 PR。

  • 请勿将重构、漏洞修复和功能开发等混合到一个 PR 中。假设您正在开发 功能 X，发现变量命名不规范或注释不完整/不正确，您应该考虑 修复这些问题，但是需要另行提交 PR，不要与功能 X 使用相同的 PR。

  • 注释很重要。您编写的代码需要长期维护。放置得当的注释 可为审核者、维护者和用户提供背景信息，还可以防止他们误解 代码的用途。但是，请勿为那些扫一眼代码就能明白的内容 添加注释。（这篇文章值得一读：https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/。）external_link

  • 测试 PR。请在 PR 中连同更改一起附上合适的单元测试和其他有用的测试， 并说明如何执行手动测试。有关单元测试的说明， 请参阅本网站以及 GitHub 上的“编码标准、测试和样式指南” 页面。

  • 允许提出反对意见：有时，审核者也会犯错。如果审核者要求您更改 PR， 而您非常坚持自己的做法，您可以自由地与审核者讨论所要求更改的优点， 但是仍需遵守行为准则。您的意见可能遭到否决，但您 也可能成功说服对方。

  • 务实：花些心思，思考如何让 PR 更容易审核和合并。任何文档 都无法取代常识和良好判断。此处分享的最佳做法和贡献指南 （若得到遵循）将有助于您的代码更轻松得到审核和合并。

常见问题

为什么我的 PR 关闭了？

系统会关闭超过 4 周的拉取请求。如果拉取请求的审核意见仍在讨论中，或者正在等待其他相关拉取请求的处理， 则可以例外处理。已关闭的拉取请求 很容易重新创建，并且如果关闭后重新打开拉取请求，之前的工作也几乎不会白费。我们 希望限制同时处理的拉取请求总数，以实现下列目标：

  • 保持项目整洁有序。
  • 删除旧的拉取请求，因为其中的基础代码已随着时间的推移而更改，因此很难重新找到最初的基础。
  • 鼓励代码速度。

为什么我的 PR 没有得到审核/合并？

  • 这可能是因为新版本即将发布导致功能冻结。在此期间，只会考虑 漏洞修复。如果您的拉取请求涉及新功能，则在发布之前不会 优先处理。请耐心等待新版本的发布。

  • 还有一种可能，即您没有遵循最佳做法。（请参阅最佳做法。）一个常见问题是 拉取请求太大，难以审核。假设您修改了 21 个文件，新增了 9347 行代码， 潜在审核者拉取差异时会望而却步，这项拉取请求需要几个小时来审核， 而他们目前没有这么多时间。他们会在有更多空闲时间时 再来处理。

  • 如果您认为上述两种情况都不是原因，而您的拉取请求仍然没有得到关注， 请在 PR 注释中添加几条提醒。如果尝试了其他方法仍无法解决问题， 请在 FreeRTOS 论坛中发布帖子并附上 PR 链接。

注意：FreeRTOS 团队保留随时更新或更改 相关指南和流程的所有权利，以维护 FreeRTOS 社区的利益。因此，建议您不时查阅本页面， 以了解最新指南和流程。