| RFC-0214：Fuchsia 变更政策 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 列举权利和责任，以减少在变更上花费的工程时间。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2022-12-22 |
| 审核日期（年-月-日） | 2023-04-03 |
摘要
更新了 Fuchsia 的管理模式，纳入了平台变更政策，要求报告变更成本、主动通知受影响的团队，并限制受影响团队的工作量。
设计初衷
Fuchsia 现在是一个大型项目，有多个独立团队在努力实现各种客户的目标。与此同时，Fuchsia 等平台必须以需要许多贡献者在代码库中付出间歇性努力的方式发展，这种方式通常称为“变动”。
目标
- 使 Fuchsia 工程实践与项目的既定支持和稳定性目标保持一致。
- 准确估算迁移和其他外部强制性变更所花费的时间。
- 明确 RFC 设计与 FPS 人员配置决策之间的界限。
- 提供一系列迁移策略供团队考虑。
非目标
- 更改已开始的大规模更改的策略。
- 确定应做出哪些更改。
- 强制要求所有变更都采用特定的迁移策略。
- 降低更改频率。
- 针对无需客户端团队付出任何努力的更改设置政策。
利益相关方
辅导员：
- abarth@google.com
审核者：
- abarth@google.com
- keir@google.com
- shayba@google.com
已咨询：
- neelsa@google.com
- tombergan@google.com
共同化：
此 RFC 最初是作为 Google 内部文档编写的，并在 Fuchsia 团队（包括 Fuchsia 工程委员会的成员）内广泛分享。
实现
此提案旨在更改 Fuchsia 的管理模式，具体内容在“受影响的团队”和“发起团队”子标题中进行了说明。如果此 RFC 获得通过，我们将通过以下方式来实现它：更新 FEC 章程、添加治理政策，以及修订新贡献者指南。
从非正式的角度来看，如果某项变更需要其他贡献者付出开发精力或更改工作流程，则该变更会被视为“Fuchsia 范围内的”变更。这包括影响 ABI、SDK 的任何公共部分、产品的内容或生成的代码的更改。
所有 Fuchsia 范围内的更改都会给许多 Fuchsia 贡献者带来工程成本。此政策可集中管理这些费用，以便尽可能降低费用。 就本政策而言，“受影响的团队”是指必须批准或更改自己的代码、工作流或文档才能适应人员流失的任何团队。
发起更改的贡献者或团队有责任解决任何中断问题。在大多数情况下，这意味着先采取“先回滚，后诊断”的方法。
受影响的团队
如果您的团队受到已获批准的变更的影响，请执行以下操作：
在两个工作日内回复收到的 CL 审核或其他更改。
支持更改作者达成令人满意的结论，例如批准其工作、回复调查问卷、明确拒绝提议的更改、要求对更改进行特定修改，以及/或回答更改作者提出的有关主题的问题。
如果您花费在应对客户流失上的时间超过 10%，可以发送电子邮件至 eng-council@fuchsia.dev 标记此问题
如果更改涉及风格指南（例如，lint、编译器警告等），您可以决定解决新风格违规问题的速度。
发起团队
如果没有流失政策，对于会造成流失的变更，就没有正式的要求或预期。此部分添加了此类更改的作者的责任。
如果您的团队发起更改并负责完成所有工作：
- 向 FEC 发送邮件，说明对其他团队的影响很小。
- 发送电子邮件至 announce@fuchsia.dev，通知贡献者进行迁移。
- 继续执行迁移。
如果您的团队发起的变更需要其他人付出大量精力，包括通过 RFC 发起的变更：
- 制定一个计划，向 FEC 证明您的团队将花费至少 80% 的人工精力来处理自动化无法解决的问题。方案必须包含受影响的团队列表以及变更的估计成本。
- FEC 批准您的方案后，请通知受影响的团队。他们必须能够使用至少两个季度的季度规划来安排工作，因此需要在季度开始前一周以上通知团队。
- 继续执行迁移。
向后兼容性
此政策不会影响任何正在进行的数据迁移。
文档
为了帮助更改作者，fuchsia.dev 上将提供迁移计划示例。
缺点、替代方案和未知因素
此提案的主要缺点是，需要在流程开始时让 FEC 参与进来。变更作者及时收到 FEC 和受影响贡献者的回复非常重要。
一种替代政策是要求受影响的贡献者批准更改。 这样做的好处是，始终允许更改作者取得进展。此替代方案被驳回，因为它会剥夺受影响的贡献者就提议的变更的价值和危害提供反馈的机会。
另一种替代方案是采用更严格的方法，即所有迁移都必须使用可用的版本控制机制进行软过渡，并以较慢的节奏将工作量分摊给所有 Fuchsia 贡献者。这与建议的政策不同，因为建议的政策对受影响的团队没有设置任何参与度预期。此替代方案已被弃用，因为它未对审核时间表设置任何界限，导致发起团队难以规划和及时取得进展。
在先技术和参考资料
在阅读此提案时，是否有任何背景材料可能会有所帮助？例如，其他操作系统是否解决了此提案要解决的相同问题？