From fd66bd29345e22c88b1087c6c87f127058b77228 Mon Sep 17 00:00:00 2001 From: happy_orange Date: Mon, 27 Jun 2022 22:48:29 -0400 Subject: [PATCH] Add review specification document --- articles/301-join-code-review.md | 58 ++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/articles/301-join-code-review.md b/articles/301-join-code-review.md index 962bd50..bb83812 100644 --- a/articles/301-join-code-review.md +++ b/articles/301-join-code-review.md @@ -1 +1,59 @@ # 参与 Review 其他社区贡献者的代码 + +Review分为两个程度：must 和 should。对于所有的 PR，must 必须遵守，should 建议遵守。 + +具体规则如下： + +| 序号 | 审视程度| 审视类别 | 审视要求 | 审视结果 | 建议修改点 | +|----|------|-----|-----------------------------------|------|-------| +| 1 | must | PR提交规范 | PR 标题清晰 | | | +| 2 | must | PR提交规范 | PR 内容描述详细具体 | | | +| 3 | must | PR提交规范 | 代码修改内容与 PR 一致，且和 changelog 一致 | | | +| 4 | must | PR提交规范 | 符合gitee的规范检查，包括源码仓的缺陷扫描和规范扫描 | | | +| 5 | must | 软件基本信息 | 软件包 name 和 package 命名匹配 | | | +| 6 | must | 软件基本信息 | 软件包的 version 为正式发布的 release/tag 版本，如果采用 rc 版本，则 version 需要定义为 xx~rc1 | || +| 7 | must | 软件基本信息 | 软件包的 epoch 用来修正版本号，但不得过度使用 | || +| 8 | must | 软件基本信息 | 需要在spec的顶端增加 anolis_release 的定义：%define anolis_release 1，release 采用：%{anolis_release}%{?dist}，每次提交 release 加一 | || +| 9 | must | 软件基本信息 | 软件包的 license 与实际的许可证相匹配，不存在缺失或者扩大 | | | +| 10 | must | 软件基本信息 | 软件包的 url 真实可用，属于上游源真实地址 | | | +| 11 | must | 软件基本信息 | 源码包来自上游开源社区，md5 值和上游相同 | | | +| 12 | must | 构建要求 | 必须要在 buildrequires 中声明所有的构建依赖 | | | +| 13 | must | 构建要求 | 必须要在 requires 中声明所有的构建依赖 | | | +| 14 | must | 构建要求 | 所有的 buildrequires 已经存在于目标版本，且完成构建（以rpm形式存在） | | | +| 15 | must | 构建要求 | 所有的 requires 已经存在于目标版本，且完成构建（以rpm形式存在） | | | +| 16 | must | 构建要求 | 至少在一种架构上构建成功，如果存在仅在部分架构上构建，可以使用 BuildArch（白名单）或者 ExcludeArch（黑名单） | | | +| 17 | must | 构建要求 | 在 %build 阶段不允许随意修改 flags，如果要修改，需要在spec中备注原因 | | | +| 18 | must | 构建要求 | 在 %build 阶段不允许随意禁用PIE | | | +| 19 | must | 构建要求 | 在 %build 阶段不允许从任何外部源下载源代码或文件 | | | +| 20 | must | 构建要求 | 在 %install 阶段复制文件时，需要保留文件的时间戳，比如 cp -p 或者 install -p | | | +| 21 | must | 补丁类要求 | source 的来源都标注清楚，不引入来路不明的文件 | | | +| 22 | must | 补丁类要求 | patch 区分上游社区和自研，自研 patch 需要在补丁头增加背景描述和影响性，且自研补丁自研补丁以100，1000，,10000开头，若冲突继续顺延。 | | | +| 23 | must | 依赖类要求 | 声明 devel 或其他子包对于主包或者 libs 的依赖时，需要增加版本限制：%{name} = %{verison}-%{release} | | | +| 24 | must | 脚本类要求 | 如果存在动态库，则必须在 %post 和 %postun 阶段调用 %ldconfig | | | +| 25 | must | 脚本类要求 | 如果存在 service 文件时，需要在 %post、%postun 和 %preun中对服务作出对应动作（比如：%post %systemd_post xxx.service） | | | +| 26 | must | files 规范 | 正确设置文件权限：目录 0755，文件 0644 root root，除非出于安全考虑需要使用特定的用户或组 | | | +| 27 | must | files 规范 | %files 里不允许有重复文件，一个文件仅能有一个归属 | | | +| 28 | must | files 规范 | %files 里不允许包含具有攻击性、歧义性、宗教性、色情性、受限制使用的文件等 | | | +| 29 | must | files 规范 | %doc 存放 readme、changelog、authors 等文件 | | | +| 30 | must | files 规范 | %license 存放 copying、license 等许可证文件 | | | +| 31 | must | files 规范 | 文件系统布局遵循FHS，个别特殊情况可以加以说明。（FHS的具体含义：https://yuque.antfin-inc.com/bobac/pm1qpi/xz4m02 11.1 文件系统布局 章节） | | | +| 32 | must | files 规范 | 头文件需要放置在 devel 包内 | | | +| 33 | must | files 规范 | 如果有静态库，则静态库需要放置在 static 包内 | | | +| 34 | must | files 规范 | 公共的目录名称不可以通过 %dir 被重复定义，比如：%{_libdir}、%{_bindir} | | ｜| +| 35 | must | files 规范 | 动态库存放规则符合要求，比如包含后缀的库文件（例如：libxx.so.1.1），则对应的午后缀的库文件比如要放在devel中（例如：libxx.so） | | | +| 36 | must | files 规范 | 有些需要保存配置的 conf 文件，需要声明 %config(noreplace) | | | +| 37 | must | files 规范 | 可以使用%find_lang 宏来处理 locale 文件，进行自动打包相关文件。例：%find_lang %{name} | | | +| 38 | must | 其他 | 有进行过安装测试和功能测试 | | | +| 39 | must | 其他 | 确保接口变更其他软件已适配 | | | +| 40 | must | 其他 | changelog的格式正确，包括：日期、版本-release等 | | | +| 41 | should | PR提交规范 | 保持一次 commit 记录，保持 PR 整洁性 | | | +| 42 | should | 软件基本信息 | 如果存在多个 license，建议给多个license加以注释 | | | +| 43 | should | 补丁类要求 | patch 的序号是连续的，并且保持一种规范，比如全是 p0 或者全是 p1 | | | +| 44 | should | 软件基本信息 | 软件 description 内容准确 | | | +| 45 | should | 构建要求 | 在 %prep 阶段采用 autospec 进行自动解压并打补丁，保持 spec 简洁，如果存在与架构相关的补丁时，可以不采用 autospec | | | +| 46 | should | 构建要求 | 在 %build 阶段尽量采用 %make_build 进行编译，多线程可以提高构建速度 | | | +| 47 | should | 构建要求 | 在 %build 和 %install 阶段使用宏变量要保持一致，比如：%{buildroot} 或者 $RPM_BUILD_ROOT | | | +| 48 | should | 构建要求 | %check 阶段能开则开，如果不能开启，声明不能开启的原因 | | | +| 49 | should | 构建要求 | 声明运行依赖 buildrequires 和 requires 时，不要添加 %{?_isa} | | | +| 50 | should | 依赖类要求 | 使用 provides 对外提供功能时，和以前版本保持一致，以前有加版本号，则需要一直加下去，如果以前没有加版本号，则不要增加 | | | +| 51 | should | 依赖类要求 | 使用 obsoletes 时，需要增加对应版本号 | | | -- Gitee