> [!WARNING]
>
> **请注意，这是社区驱动的官方 syzkaller 文档翻译。当前文档的最新版本（英文版）可在 [docs/maintaining.md](/docs/maintaining.md) 中找到。**

# 维护者指南

## 线性历史

我们保持线性历史记录，并在仓库设置中禁用合并提交（merge commit）。
拉取请求（PR）仅有两个选项：
- **变基合并（Rebase and merge）**\
  若 PR 中的所有提交已妥善整理/修复，优先选择此方式，
  因其保留 PR 中的提交记录（将 PR 中的所有提交直接添加至 master 分支的最新提交之上）。
- **压缩合并（Squash and merge）**\
  若 PR 包含分散的修正提交或提交组织混乱时优先选择此方式
  （将 PR 中的所有提交压缩为单个提交并添加至 master 分支的最新提交之上，同时允许编辑提交主题/描述）。

## PR 检查 (CI)

合并前需通过 `cla/google` 检查。

合并前通常需通过所有 CI 测试。\
例外情况包括基础设施偶发问题（尤其是外部服务：`codecov`、`ci/fuzzit`）
以及偶现的超时/内存溢出（但若 PR 本身显著增加此类问题频率则不可豁免）。所有静态检查警告和测试错误均视为严重问题。

## 测试

原则上鼓励为新代码和错误修复添加测试。应要求贡献者补充测试。

但不同代码的测试难度存在差异。
以下情况更易添加测试（建议补充）：无外部依赖的抽象功能（如解析器、数据转换、计算逻辑）；已有成熟测试基础设施的代码（添加新测试仅需遵循现有模式）。
以下情况测试难度较高（可不强制要求，但仍欢迎补充）：存在难以模拟的外部依赖的代码（qemu、内核、镜像等）；缺乏现成测试基础设施，需先构建整套框架才能添加测试的代码。

## 善用判断力

当前暂无严格的审查/所有权规则，请灵活运用判断力。

若您负责项目的特定领域（如某操作系统的支持），可自行合并变更而无需额外审查（尤其小型变更且 CI 通过时）。
亦可审查并合并项目其他部分的变更。若信心不足或需要额外意见，请与其他维护者协同处理。
