中英文混排

UTsweetyfish · BLumia · commit 89f1db6645ea · 2025-07-08T17:36:11.000+08:00
diff --git a/rfcs/0000-template.md b/rfcs/0000-template.md
@@ -35,4 +35,4 @@
 
 ## 替代方案
 
-描述此提案相关的，你所考虑的潜在替代方案。
+描述此提案相关的，你所考虑的潜在替代方案。
diff --git a/rfcs/0004-package-removal-guideline.md b/rfcs/0004-package-removal-guideline.md
@@ -11,9 +11,9 @@
 
 在维护 deepin 软件源的过程中，我们发现了一些软件包已经不再维护，但是仍然存在于软件源中，这些软件包可能会造成一些问题，例如：
 
-  1. 可能会造成用户的误用，导致用户的系统出现问题
-  2. 出现 CVE 漏洞，但是由于软件包已经不再维护，无法及时修复
-  3. 有新的软件包可以替代，但是由于软件包已经不再维护，无法及时替换
+1. 可能会造成用户的误用，导致用户的系统出现问题
+2. 出现 CVE 漏洞，但是由于软件包已经不再维护，无法及时修复
+3. 有新的软件包可以替代，但是由于软件包已经不再维护，无法及时替换
 
 我们需要完善软件源中包退出的流程，以便及时发现软件包的退出，并及时通知用户。现有流程：https://wiki.deepin.org/zh/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E7%AE%A1%E7%90%86
 
@@ -22,14 +22,14 @@
 在 deepin-community/Repository-Manager 仓库下新建一个新的配置文件 removed-packages.yaml，用于记录软件包退出的信息，格式如下：
 
 ```yaml
-- name: package_name  # 软件包名称
+- name: package_name # 软件包名称
   version: package_version # 软件包版本
   reason: package_remove_reason # 软件包退出原因（例如：不再维护、存在安全漏洞等）
   replacement: package_replacement # 软件包的替代方案（可选）
   remove_time: package_remove_time # 软件包退出时间（指的是节点时间，例如：2023-06-14）
   remove_type: package_remove_type # 软件包退出类型（指的是软件包的类型，例如：main、dde、community 等）
   remove_by: package_remove_by # 软件包退出人（指的是软件包退出的发起人，例如：SIG 组成员、社区成员等）
-  remove_repo: package_remove_repo # 软件包退出仓库（指的是软件包退出的仓库，例如：ci、testing、stable 等） 
+  remove_repo: package_remove_repo # 软件包退出仓库（指的是软件包退出的仓库，例如：ci、testing、stable 等）
 ```
 
 并配置 CI，当软件包移除 pr 被提出时，CI 会检查软件包是否被依赖，列出依赖软件包的列表。
diff --git a/rfcs/0007-rust-pkg-maintain.md b/rfcs/0007-rust-pkg-maintain.md
@@ -5,23 +5,23 @@
 
 ## 概要
 
-为rust系列软件包添加新的维护方式
+为 rust 系列软件包添加新的维护方式
 
 ## 动机
 
-rust系列软件包数量预计有1700+ ，新增这些包会导致github组织下仓库增长过快有滥用github repo风险，参照当前的维护方式不利与rust系列软件包的维护。
+rust 系列软件包数量预计有 1700+ ，新增这些包会导致 github 组织下仓库增长过快有滥用 github repo 风险，参照当前的维护方式不利与 rust 系列软件包的维护。
 
 ## **详细设计**
 
-在deepin-community下新建rust-pkg项目，这个项目存放存放所有rust相关软件包的debian目录等文件，从crates.io 拉取源码，CI/CD流程自动生成dsc orig等打包必须的文件自动化上传到OBS中进行构建，检查构建是否通过，PR合并后自动submit到对应的组件中去(main or  community)
+在 deepin-community 下新建 rust-pkg 项目，这个项目存放存放所有 rust 相关软件包的 debian 目录等文件，从 crates.io 拉取源码，CI/CD 流程自动生成 dsc orig 等打包必须的文件自动化上传到 OBS 中进行构建，检查构建是否通过，PR 合并后自动 submit 到对应的组件中去(main or  community)
 
 ## 提案弊端
 
-弊端：区别于现有的包维护形式，需对CI/CD流程进行调整
+弊端：区别于现有的包维护形式，需对 CI/CD 流程进行调整
 
 ## 遗留问题
 
-这种维护方式后续是否扩展到其他类型的软件包维护工作中，例如golang相关的软件包
+这种维护方式后续是否扩展到其他类型的软件包维护工作中，例如 golang 相关的软件包
 
 ## 替代方案
 
diff --git a/rfcs/0012-changelog-specification.md b/rfcs/0012-changelog-specification.md
@@ -1,4 +1,4 @@
-# 统一的changelog版本号规范
+# 统一的 changelog 版本号规范
 
 - 提案发起时间：2024-07-25
 - 提案拉取请求：https://github.com/deepin-community/rfcs/pull/12
@@ -9,69 +9,73 @@
 
 ## 动机
 
-明确版本号规范标记软件包修改信息、来源，方便通过版本号追踪与上游版本差异，提供更合理的rebuild版本机制。
+明确版本号规范标记软件包修改信息、来源，方便通过版本号追踪与上游版本差异，提供更合理的 rebuild 版本机制。
 
 ## 详细设计
 
-**changelog版本规范**
+**changelog 版本规范**
 
 `upstreamversion-${ver1}deepin${ver2}`
 
-#### 1. 假设上游项目打包版本号为 x.y.z ，deepin打包版本则为 `x.y.z-${ver1}deepin${ver2}` 
+#### 1. 假设上游项目打包版本号为 x.y.z ，deepin 打包版本则为 `x.y.z-${ver1}deepin${ver2}`
 
-- ver1：ver1为0时表示 deepin自行打包的上游软件，ver1不为0时表示来自上游的quilt软件包自带的-ver版本
-- ver2：表示来自deepin社区的修改，依次递增，不可为空从0开始计算
+- ver1：ver1 为 0 时表示 deepin 自行打包的上游软件，ver1 不为 0 时表示来自上游的 quilt 软件包自带的-ver 版本
+- ver2：表示来自 deepin 社区的修改，依次递增，不可为空从 0 开始计算
 
-#### 2. 来自deepin community自行打包的上游软件 以0deepin开头标识，若该项目添加了来自deepin的patch则以deepin1 标识，依次累加, 版本号形式x.y.z-0deepin1 , 若上游已经添加-2这类版本号，版本号则为 x.y.z-2deepin1
+#### 2. 来自 deepin community 自行打包的上游软件 以 0deepin 开头标识，若该项目添加了来自 deepin 的 patch 则以 deepin1 标识，依次累加, 版本号形式 x.y.z-0deepin1 , 若上游已经添加-2 这类版本号，版本号则为 x.y.z-2deepin1
 
-#### 3. 集成native软件包
-将native软件包直接改成quilt格式存在一些changelog版本格式不兼容问题
-因此重新修订native版本规范，形式为 `upstreamversion+deepin${ver2}`
-native软件包没有-的连字符，因此直接在上游版本号后添加+deepin${ver2} 标记来自deepin的修改
+#### 3. 集成 native 软件包
+
+将 native 软件包直接改成 quilt 格式存在一些 changelog 版本格式不兼容问题
+因此重新修订 native 版本规范，形式为 `upstreamversion+deepin${ver2}`
+native 软件包没有-的连字符，因此直接在上游版本号后添加+deepin${ver2} 标记来自 deepin 的修改
+
+#### 4. CI 自动构建版本号 `x.y.z-${ver1}deepin${ver2}+u001+rb1`，001 为距离上一次修改 changelog 的 commit 次数，rb1 为 rebuild 次数，依次累加
 
-#### 4.  CI自动构建版本号 `x.y.z-${ver1}deepin${ver2}+u001+rb1`，001为距离上一次修改changelog的commit次数，rb1为rebuild次数，依次累加
 > [!WARNING]
-> 注：commit版本号使用仅限于开发阶段自测验证，不应流转到集成阶段
+> 注：commit 版本号使用仅限于开发阶段自测验证，不应流转到集成阶段
+
+#### 5. rebuild 版本号规范
 
-#### 5. rebuild版本号规范
-上文一二条保持不变，若存在需要rebuild软件包，
+上文一二条保持不变，若存在需要 rebuild 软件包，
 
-##### quilt软件包rebuild规范：
+##### quilt 软件包 rebuild 规范：
 
-情况1：ver2不为空时直接+rb{ver}后缀，表现形式为`x.y.z-1deepin1+rb1`
+情况 1：ver2 不为空时直接+rb{ver}后缀，表现形式为`x.y.z-1deepin1+rb1`
 
-情况1：ver2为空时的rebuild版本ver2默认为0，表现形式为
-  `x.y.z-1deepin0+rb1`
-  
-##### native软件包rebuild规范：
+情况 1：ver2 为空时的 rebuild 版本 ver2 默认为 0，表现形式为
+`x.y.z-1deepin0+rb1`
 
-情况1：ver2不为空时直接+rb{ver}后缀，表现形式为`x.y.z+deepin1+rb1`
+##### native 软件包 rebuild 规范：
 
-情况1：ver2为空时的rebuild版本ver2默认为0，表现形式为
-  `x.y.z+deepin0+rb1`
+情况 1：ver2 不为空时直接+rb{ver}后缀，表现形式为`x.y.z+deepin1+rb1`
+
+情况 1：ver2 为空时的 rebuild 版本 ver2 默认为 0，表现形式为
+`x.y.z+deepin0+rb1`
 
 > [!WARNING]
-> 注：rebuild版本号使用仅限于依赖包升级，相关依赖树需要基于新版本构建编译的场景使用
+> 注：rebuild 版本号使用仅限于依赖包升级，相关依赖树需要基于新版本构建编译的场景使用
 
 > [!TIP]
-> 注： deepin0版本的用意是为了方便后续的更新迭代，按照版本号规则 deepin+rb1版本大于deepin1+rb1，所以使用deepin0后缀方便后续维护
+> 注： deepin0 版本的用意是为了方便后续的更新迭代，按照版本号规则 deepin+rb1 版本大于 deepin1+rb1，所以使用 deepin0 后缀方便后续维护
 
 #### 6. 安全更新版本规范：
 
 - 对于相同版本软件包需要在两个以上的版本中做安全更新(例如 v23 and v26)时，为确保版本号正确，必须大于当前软包版本且小于后续发行版中的软件包版本，请示在版本号后缀中添加+dp${version}u${num}形式
-- 对于v23版本 `upstreamversion-${ver1}deepin${ver2}+dp23u1` 对于v26版本 `upstreamversion-${ver1}deepin${ver2}+dp26u1` ，对于首次更新${ver2}值应当增加假设{ver2}为1 更新后应该为1.1此举是为了区别于主线版本号避免影响主线上的rebuild版本机制，对于主线的安全更新版本{ver2}加1即可， 对于后续的更新，$num值都应当累加，由于版本号形式较多建议使用 `dpkg --compare-versions` 验证版本号是否符合要求。
+- 对于 v23 版本 `upstreamversion-${ver1}deepin${ver2}+dp23u1` 对于 v26 版本 `upstreamversion-${ver1}deepin${ver2}+dp26u1` ，对于首次更新${ver2}值应当增加假设{ver2}为1 更新后应该为1.1此举是为了区别于主线版本号避免影响主线上的rebuild版本机制，对于主线的安全更新版本{ver2}加1即可， 对于后续的更新，$num 值都应当累加，由于版本号形式较多建议使用 `dpkg --compare-versions` 验证版本号是否符合要求。
 - 参考的形式 原版本 `upstreamversion-1deepin1` 安全更新版本 `upstreamversion-1deepin1.1+dp23u1`
-- 当deepin${ver2} 不存在时，此时安全更新的ver2版本应该使用0.1 主线版本使用1 避免与主线版本冲突, 参考的形式`upstreamversion-1deepin0.1+dp23u1`
+- 当 deepin${ver2} 不存在时，此时安全更新的 ver2 版本应该使用 0.1 主线版本使用 1 避免与主线版本冲突, 参考的形式`upstreamversion-1deepin0.1+dp23u1`
 - 对于非上述情况时应当遵循上文的版本号规范提交。
-> [!TIP]
-> 注： dp为deepin的缩写
+  > [!TIP]
+  > 注： dp 为 deepin 的缩写
 
 > [!TIP]
 > 注： 历史遗留的版本号不在本次讨论范围内，新的提交的软件包构建集成等应遵循新版本规范
 
-
 #### 7. 总结
-##### BNF规则
+
+##### BNF 规则
+
 ```
 <digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
 <nonzero_digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
@@ -126,16 +130,18 @@ native软件包没有-的连字符，因此直接在上游版本号后添加+dee
 附带一个 BNF Playground: https://bnfplayground.pauliankline.com/
 
 > [!TIP]
-> 可参考BNF验证自己写的版本号是否符合规范
+> 可参考 BNF 验证自己写的版本号是否符合规范
 
 ##### 完整的构造
+
 `upstreamversion-${ver1}deepin${ver2}[+dp26u${num}][+u${ver3}][+rb${ver4}]`
- - ${ver1} 来自deepin的上游的版本
- - ${ver2} 来自deepin的patch版本,这块必须，且从0开始 如无任何修改则不需要加该字
- - [+dp26u${num}] 安全补丁版本，这块只有在多版本发布安全补丁时需要
- - [+u${ver3}] CI编译版本，只有CI开发环境编译时有
- - [+rb${ver4}] rebuild次数，这块只有rebuild时才添加
- - 主线 GitHub 版本为 `upstreamversion-${ver1}deepin${ver2}`
- - 主线仓库会有 [+rb]，不在GitHub，在OBS生成；
- - 安全更新在 GitHub，非主线，有 [+dp26u${num}]；
- - [+u${ver3}] 为开发版本，在GitHub内不出现，在仓库内不出现，但是出现在 CI 中
+
+- ${ver1} 来自 deepin 的上游的版本
+- ${ver2} 来自 deepin 的 patch 版本,这块必须，且从 0 开始 如无任何修改则不需要加该字
+- [+dp26u${num}] 安全补丁版本，这块只有在多版本发布安全补丁时需要
+- [+u${ver3}] CI 编译版本，只有 CI 开发环境编译时有
+- [+rb${ver4}] rebuild 次数，这块只有 rebuild 时才添加
+- 主线 GitHub 版本为 `upstreamversion-${ver1}deepin${ver2}`
+- 主线仓库会有 [+rb]，不在 GitHub，在 OBS 生成；
+- 安全更新在 GitHub，非主线，有 [+dp26u${num}]；
+- [+u${ver3}] 为开发版本，在 GitHub 内不出现，在仓库内不出现，但是出现在 CI 中

Original file line number	Diff line number	Diff line change
`@@ -35,4 +35,4 @@`
`35`	`35`
`36`	`36`	`## 替代方案`
`37`	`37`
`38`		`-描述此提案相关的，你所考虑的潜在替代方案。`
	`38`	`+描述此提案相关的，你所考虑的潜在替代方案。`