工作流程
Mbed OS 的所有代码更改和添加都通过 GitHub 处理。如果您想通过添加功能或修复错误来做出贡献，请遵循新功能和错误的指导原则。在这两种情况下，请遵循代码样式指南和 GitHub 拉取请求指南。另请阅读贡献者许可协议（CLA）指南，因为我们将立即关闭在没有 CLA 的情况下提交的拉取请求。
Mbed OS 维护者
维护者是一小群 Mbed OS 工程师，他们负责 Mbed OS 代码库。它们的主要作用是从最初的拉取请求状态到发布的代码，促进内部和外部的贡献。
工作职责：
- 检查 CLA 合规性。
- 确保相关的利益相关者审查拉取请求。
- 从技术和程序上指导贡献者。
- 通过 CI 系统运行拉取请求。
- 放标签版。
- 将拉取请求合并到请求的分支中。
- 定期发布补丁和功能。
目前的维护者是：
贡献
在提供增强功能（新功能，新端口等）之前，请在论坛上讨论它以避免重复工作，因为我们或其他人可能正在开发相关功能。
如果您从我们的存储库的分叉版本创建拉取请求，我们只能通过 GitHub 接受贡献。这使我们能够在公众监督下以易于使用和可靠的方式审查贡献。
请为每个问题创建单独的拉取请求；每个拉取请求都需要明确的目标统一。特别是，单独的代码格式和样式更改功能更改。这使得每个拉取请求的真实贡献更加清晰，因此审查更快更容易。
报告错误
请在论坛上提交所有 Mbed OS 错误。
错误报告应该是可重现的（对其他人来说是失败的）和具体的（失败的地点和方式）。我们将关闭不足的错误报告。
我们将 GitHub 上报告的问题复制到我们的内部跟踪器（ARM 内部参考：问题中的 MBOTRIAGE-XXX 注释，并在复制后标记镜像集）并定期对它们进行分类。
GitHub 拉取请求指南
GitHub 上的拉取请求必须满足以下要求才能保持代码和提交历史记录清洁：
- 提交应始终包含对其内容的正确描述。从简洁明了的单行描述开始。然后，详细说明所做出的选择的推理，审阅者的描述以及可能会丢失的其他信息。
- 您应该始终编写提交以允许发布，因此它们永远不会包含机密信息，引用私有文档，指向内部网位置的链接或粗鲁的语言。
- 每次提交都应该是更改的最小自包含提交。提交应始终导致再次处于可编译状态的新状态。您应该（如果可能的话）将大的更改拆分为逻辑较小的提交，以帮助审阅者遵循完整更改背后的推理。
- 提交和提取请求标题应遵循 Chris Beam 的七条重要提交消息规则：
- 用空白线将主体与身体分开。
- 将主题行限制为 72 个字符（请注意，这是与 Beam 标准的偏差）。
- 大写主题。
- 不要以句点结束主题行。
- 使用主题行中的命令式表情。
- 包裹身体 72 个字符。
- 用身体解释什么以及为什么和如何。
- 因为我们使用 GitHub 和显式 CLA，所以其他项目可能使用的特殊提交标记（例如 “Review-by” 或 “Signed-off-by”）是多余的，应该省略。GitHub 跟踪谁审查了什么和什么时候，我们的签名 CLA 堆栈向我们展示了谁同意我们的开发贡献协议。
- 使用域前缀提交消息是可以接受的，我们建议在有意义的情况下这样做。但是，在一个域的前面加上 repo 的名称是没用的。例如，向 mbed-drivers repo 提交一个名为 “mbed-drivers：Fix doppelwidget frobulation” 的提交是不可接受的，因为已经知道提交适用于 mbed-drivers。如果我们假设 “doppelwidget” 是一个有意义的变更域，那么将提交重命名为 “doppelwidget：Fix frobulation” 会更好，因为它传达的变化适用于 mbed-drivers 的 doppelwidget 区域。
- 所有新功能和增强功能都需要文档，测试和用户指南供我们接受。请将每个拉取请求链接到所有相关文档和测试拉取请求。
- 避免合并提交。（如果可能的话，一定要改变）。
- 在每次更改（rebase 或新提交）上的拉取请求中进行注释。这有助于审阅者了解最新动态
- 拉取请求应修复错误，添加功能或重构。
发布版本
您可以在 How We Release Arm Mbed OS 上找到 Mbed OS 版本。
拉取请求类别
Bug 修复
每个错误修复都应包含一个测试，以验证拉取请求之前和之后的结果。
变化和补充
向后兼容的更改（例如重构和增强）或新的目标添加可以用于补丁和功能发布。我们只考虑功能发布的功能和新功能。
特征
我们最初在 Mbed OS 存储库中的不同分支上实现新功能。Mbed OS 维护者遵循命名约定创建新分支：“feature-” 前缀。
每个功能都有技术领先。此人负责：
- 经常重新定位以跟踪主开发。
- 查看功能分支的任何添加内容（功能技术主管或其他指定人员要求的批准）。
拉取请求类型
我们考虑以下拉取请求类型。
修复
错误修复是向后兼容的内部更改，可修复不正确的行为。
发布：补丁
重构
如果功能发布没有修复特定问题，则重构将用于功能发布，因为它们可能会引入新问题。
发布：功能
新目标
添加新目标是修补程序版本的更改，因为它更新了目标文件夹实现。
发布：补丁
特征
新功能目标功能发布。只有在功能支持大多数目标时才能集成新功能（如果它需要新的目标 HAL 实现）。
我们考虑添加新功能作为功能。无论是 C++，C 还是 Python 都没关系。
发布：功能
打破变革
突破性变化是导致用户空间中断的任何变化。它应该有充分的理由让我们考虑它。通常，此类更改可以向后兼容，例如，弃用旧功能并引入新替换。
发布：重大
拉取请求模板
以下是拉取请求的一个很好的例子：
Fix deep sleep locking bug
# Description
Fix problems that could leave deep sleep locked unintentionally, along with adding tests to verify this behavior is fixed.
Tested locally with two targets and all toolchains.
You can see test results [here](just an example).
# Pull request type
[x] Fix
[ ] Refactor
[ ] New Target
[ ] Feature
GitHub 拉取请求工作流程
每个拉取请求都通过以下工作流程：
合并拉取请求的工作流程
拉取请求状态
Mbed OS 维护者为表示拉取请求工作流状态的拉取请求添加标签。Mbed OS 维护者负责通过工作流状态移动拉取请求。
每个状态都是时间盒装。在大多数情况下，这是移居到另一个状态的充足时间。如果在时间范围内没有提供更新，则可以关闭拉取请求。
审查
必须审查所有拉取请求。Arm Mbed CI 机器人确定最适合审查拉取请求的人并相应地标记该人。
在对拉取请求提交历史记录进行任何更改（例如添加新提交或重新定位）后，Github 会驳回审阅者的状态。较小的更改，例如最新版本之上的文档编辑或 rebase，只需要维护人员进行额外的审核。他们的批准是足够的，因为被指派为审阅者的团队已经批准了拉取请求。
时间：在维护者添加 “需求：审核” 标签后，审核人员需要 3 天时间留下反馈。
CI（持续集成）测试
有许多 CI 系统可用。我们针对特定拉取请求运行的 CI 测试取决于拉取请求对代码库的影响。无论运行哪些 CI 测试，Mbed OS 都具有全绿色策略，这意味着在合并拉取请求之前，所有被触发的 CI 作业必须通过。
时间：CI 完成并报告结果 1 天。
需要的工作
工作所需状态下的拉取请求由于测试失败而需要额外的工作，或者由于审查而需要返工。如果拉取请求处于此状态，那么我们的维护者会从拉取请求作者请求更改。
时间：拉取请求作者执行审核评论的 3 天。
发布
当我们合并我们将在补丁版本中发布的拉取请求时，我们使用特定补丁版本标记拉取请求。这是我们首次发布此拉取请求的版本。对于补丁版本，我们仅允许错误修复，新目标和现有功能的增强。新功能仅适用于功能发布。
发布标记具有以下格式：
release-version：5.f.p - 其中 f 是功能发布，p 是补丁发布。
附加标签
我们使用许多其他标签来总结变更的范围和效果。
- 需求：在 PR 之前 - 此拉取请求尚未合并，因为它依赖于需要首先合并的另一个拉取请求。
- 请勿合并 - 此拉取请求包含可能处于草稿状态并仅提交审核的更改，或者可能包含尚未考虑的重大更改。
- 设备：'名称' - 拉取请求专门影响指定的设备。
- 部件：'名称' - 拉取请求专门影响命名组件。
以下标签总结了拉取请求的范围。
- 范围：错误修复。
- 范围：功能。
- 范围：新目标。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
