目录

参与 Review 其他社区贡献者的代码

本文章介绍了代码 Review 过程中的细节和注意点，希望更好的帮助到代码提交者和 reviewer，让代码提交和代码合入都变得简单。

1. 综述

1.1 前提介绍

本文章已经假设 source 仓库（anolis）或 rpm 仓库（src-anolis-os 和 src-anolis-sig）已经存在，不涉及软件引入流程（304 龙蜥社区软件包引入和管理原则）。

1.2 文档范围

本文章涵盖：

1.3 修定记录

时间 作者 描述 审核人
2022/12/01 happy_orange v1.0 - 初始版本  
2022/08/09 happy_orange v1.1 - 调整 review 项  

2. source 仓库 Review 规范

2.1 规则介绍

maintainer 可以按照自己的意见填写审核结果，[+] 代表通过，[-] 代表不通过，不通过的点建议给出不通过原因或者建议修改方式。

2.2 Review 模版

类别 审核要求 审核级别 审核结果 意见项
提交规范 PR 标题清晰 must    
  应该尽可能描述清楚 PR 的修改内容和影响性 must    
   代码实际修改内容与 PR 一致 should    
代码规范 代码简洁、易懂，可读性高 must    
  符合 gitee 的规范检查，包括源码仓的缺陷扫描和规范扫描 must    
引入三方规范 不引入 license 不明的文件或者依赖 must    
  有存在三方引入时，声明来源 must    

3. rpm 仓库 Review 规范

3.1 规则介绍：

maintainer 可以按照自己的意见填写审核结果，[+] 代表通过，[-] 代表不通过，不通过的点建议给出不通过原因或者建议修改方式。 

3.2 Review 模版

类别 审核要求 审核级别 审核结果 意见项
门禁规范 门禁全部通过，如果因为门禁环境原因，需要给出合理解释 must    
提交规范 PR 标题清晰 must    
  PR 内容描述详细具体，尽可能描述清楚 PR 的修改内容和影响性 must    
  代码实际修改内容与 PR 一致 must    
spec-基本信息 符合 《https://anolis.gitee.io/docs/articles/305-module-and-checklist-of-spec.html》中的字段要求 must    
  不升级时 anolis_release 采取递增，升级时，anolis_release 从 1 开始。 must    
  patch 和 souce 采用序号区分自研和开源三方  must    
  涉及具体架构的专项更改时，使用架构作为判断条件 must    
  changlog 格式正确，并且提交信息简单易懂 must    
source 文件 目录结构清晰，仅包括：spec、source.tag.gz、patch、source，不存在其他文件 must