!487 社区规范刷新（issue处理、门禁、版本质量、编译规范）

* 新增issue处理指导，代码门禁要求，版本质量要求，编译规范

sig/sig-QA/Openharmony 编译规范.md

+# Openharmony 编译规范
+
+## 目的和范围
+
+Openharmony 编译规范用于指导开发者规范地编写和修改编译相关的源码、脚本和工具，保证编译过程正确，可信，可重复和高效。
+
+## 术语
+
+### 编译框架
+
+Openharmony的编译系统就是用来构建Openharmony操作系统的一组软件，主要由模块编译模板，配置框架、发布框架组成。
+
+Openharmony的编译系统主要由GN语言和python编写完成，通常GN用于描述编译过程和依赖关系，python用于执行特定的编译目标
+
+本文主要描述GN的相关编写要求
+
+### GN
+
+GN : Generate Ninja,   开源的编译工具，使用.gn文件定义和描述编译过程，并生成最终的编译过程清单，即ninja文件
+
+### Ninja
+
+Ninja: 开源的编译执行工具，高效执行ninja文件描述的编译过程清单
+
+## GN 编写规范
+
+### 规则1.1  
+
+**禁止** ：在gn中调用外部编译工具编译软件模块。
+**反例** ：在gn中使用action调用automake和Make来编译三方组件。
+**要求**  ：需要将外部组件移植成gn的编译形式，避免编译过程对环境产生不必要的依赖，而且可获得编译框架提供的公共能力，包括不限于：安全编译选项，ASAN等。
+**例外**  ：Linux Kernel 编译框架实际完成的用户态程序编译，内核完全可以在编译框架之外完成独立编译。某些平台实现为了实现一键编译，使用gn将内核编译加在编译过程中，是可以接 受的
+
+### 规则1.2
+
+**禁止** ：禁止在模块的gn文件中，再次添加编译系统已经添加的安全编译选项。
+**反例** ：在模块的编译添加 `` -fstack-protector-strong``	
+**要求**  ：对于全局已经添加的默认选项，模块开发者应当知晓，不需要为了满足内外部规则再次添加
+
+| 编译选项  | 编译参数  | 默认值  |
+|--|--|--|
+| 栈保护  |  -fstack-protector-strong |  开 |
+| Fortify Source  |  -D_FORTIFY_SOURCE=2 -O2 |  开 |
+
+### 规则1.3
+
+**禁止** ：在gn中添加和默认编译选项相反的编译选项
+**反例** ：在自研模块中添加 ``-wno-unused`` 以消除编译告警
+**要求**  ：默认的编译选项代表了系统的默认能力，自研模块有特殊情况需要去掉部分能力，必须有足有的理由
+**例外**  ：移植三方组件，或者使用因为三方组件时，可根据三方组件的要求覆盖默认的编译选项
+
+### 规则 2.1
+
+**要求** ：使用gn format 对添加或者修改的gn文件进行格式化，满足格式和排版的需求
+
+### 规则 2.2
+
+**建议** ：编写action时，使用python而不是shell
+**说明** :  python 环境更容易保持统一，可以比较容易的多重操作系统上运行，并且扩展性可读性可测试更好
+
+### 规则 2.3
+**规则**：禁止在gn和ninja执行过程修改源码目录的内容
+**说明**：包括但不限于给源码目录打patch，向源码目录中拷贝，在源码目录中执行编译，在源码目录生成中间文件等
+
+### 规则 2.4
+**规则**：编译脚本的编码格式设置为utf-8，换行符设置为unix格式
+**反例** ：在windows上编写脚本后，使用了中文注释并保存为本地编码
+
+
+

sig/sig-QA/issue（缺陷类）处理指导.md

+### 缺陷来源
+分两种：社区开发者提交的需求和测试sig在测试过程发现的缺陷提交的issue。
+<br>
+整体出来过程如下图：
+
+![图片说明](http://image.huawei.com/tiny-lts/v1/images/f81aa437fe1f4f18531aa956ead45a00_1035x656.png@900-0-90-f.png)
+### 缺陷的创建
+[规则 1]：所有缺陷创建按照模板提交
+**【模块名_概率】简要描述：**
+
+ **【环境信息】:** 
+- 网络环境
+- 硬件开发板型号
+- 软件版本信息或tag节点
+- 测试环境
+- 其他
+
+ **【预置条件】:**
+
+ **【测试步骤】：**
+
+ **【预期结果】：**
+
+ **【实际结果】：**
+
+ **【恢复手段】：**
+
+ **【出现概率】：问题出现次数/实际测试次数**
+
+ **【定位信息】：**
+
+- 1. Log、截图、多媒体文件等，所有和问题有关的信息：
+
+### 缺陷审核
+- [规则 1]：缺陷审核责任人：测试提交缺陷由测试sig组织确认和审核，社区开发者提交缺陷由sig组组织确认和审核<br>
+- [规则 2]：issue各字段需要确保正确，正确的issue字段是度量的基础，在审核环节需要刷新issue的状态，issue的优先级、指定issue责任人<br>
+- [规则 3]：如果经过审核和提交人达成一致，明确是非问题的，可以直接关闭，状态为“已取消”<br>
+- [规则 4]：如果经过审核和提交人达成一致，明确是已知重复问题的，可以把已知issue号关联起来，可以直接关闭，状态为“已取消”<br>
+- [规则 5]：如果经过审核和提交人达成一致，明确是问题，但是版本不解决，当前可以直接关闭，状态为“挂起”<br>
+- [规则 6]：如果经过审核和提交人无法达成一致，此类缺陷提交到联合sig组，组织技术评审，按照评审结论执行，或解决或挂起<br>
+
+### 缺陷的修改
+- [规则 1]：缺陷修改描述清楚问题发生原因和定位过程。<br>
+- [规则 2]：先定位后修改，原因分析需填写原因分析和修改方案，如有设计文档，按需附上设计文档，指导后续的测试设计和验证。<br>
+- [规则 3]：测试用例设计，白盒自动化用例要做到代码逻辑全覆盖，手工测试用例要做到修改场景上的覆盖。建议：如果修改代码量在50行以下，设计测试用例不少于5条；50行及以上，测试用例在代码行的10%以上；<br>
+- [规则 4]：如果问题单涉及多人、多sig组同步修改或上下层同时修改，建议新建issue，把相关issue关联起来<br>
+- [规则 5]：如果转给其他责任人修改，需要和对应sig组对齐达成一致后转移责任人，如果issue所属代码仓错误，和对应仓责任人沟通确认后编辑修改到正确代码仓。代码仓和责任人是issue度量的基础，度量看板严格按照代码仓和责任人卷积到对应组织。<br>
+- [规则 6]：首问责任制：issue的处理按照首问责任制执行，issue提交到哪个代码仓下，首问哪个代码仓对应的sig组负责组织定位<br>
+- [规则 7]：缺陷的状态是缺陷管理的基础，需要责任人及时更新缺陷的状态字段，OpenHarmony社区定义的状态有如下：<br>
+
+|  序号 |状态   |处理责任人   |说明   |
+| ------------ | ------------ | ------------ | ------------ |
+|1   | 待办的  | 提交者  |   |
+| 2  | 已确认  | sig组  | 按照测试sig提交缺陷有测试组织确认，开发者提交缺陷由sig组组织确认  |
+| 3  | 技术评审中  | 联合sig  | 对缺陷方案有争议，要到联合sig/PMC上决策  |
+| 4  | 修复中  | sig组  | sig组负责修复并提交pr  |
+| 5  | 验收中  | 测试或issue提交者  | pr提交后走到测试验收或对应提交者验收  |
+| 6  | 已完成  | 测试或issue提交者  | 经过验收后状态走到已完成状态，表示issue处理闭环  |
+| 7  | 已取消  | 测试或issue提交者  | 经过确认和提交者达成一致意见后可以取消  |
+| 8  | 已拒绝  | sig组  | 经过确认和提交者达成一致意见后，可以决绝  |
+| 9  | 已挂起  | sig组  | 经过确认和提交者无法达成一致意见经过联合sig/PMC评审决策后问题可以挂起，暂不解决，明确后面版本解决计划  |
+
+
+
+

sig/sig-QA/issue（需求类）处理指导.md

+### 需求的收集及决策：
+- 需求收集责任人：社区开发者随时可以提交需求类issue，对应sig负责需求收集和整理。
+- 需求决策组织：sig组需求分析后提交PMC组织需求价值评审和排序，在PMC决策接纳或拒绝需求。
+
+### 需求交付计划制定
+- 里程碑制定：release-sig组发布迭代交付里程碑。
+- 需求交付计划：所有需求经PMC评审后接纳的需求，需要明确交付计划，每个需求必须指定里程碑点，并按照计划交付。
+
+### 需求分解及依赖管理
+原始需求颗粒度不同，需要经过分解形成可以指导开发的需求列表，一个需求如果描述不清楚需要分解到场景清晰、能够验收、质量目标明确（性能、功耗等基础特性）的粒度，需求的分解通过子任务和父任务进行关联关联，所有原始需求作为一级需求，每个原始需求建议分解到一个二级需求（子任务），如果二级需求依然粒度大，可以继续分解，直至能够达成需求描述可以直接指导开发实现的程度，建议最高分解到三级需求（三级子任务）：
+- 建议所有原始需求要分解到二级需求。
+- 所有最终分解的需求达成场景清晰、可验收、质量目标明确的目标。
+- 最小化原则：每个最小粒度需求不跨仓，唯一一个开发者完成。
+- 如果需求和其他需求依赖，必须指定需求依赖关系。
+- 需求分解需要指定协作者，协作者需要包括测试，安全和资料，协作者负责对应领域的需求评审，所有需求必须经过协作者评审通过。
+- 每个需求分解需明确性能、功耗、安全等基础特性对应规格目标。
+- 每个需求如果涉及对外接口或对开发者使用有变化，必须分解一个文档类需求。
+- 设计方案变更或大粒度需求，要输出设计文档，每个sig组维护一个模块设计文档。
+
+### 需求分配
+- 每个需求明确责任人。
+- 每个需求需预估工作量。
+- 开发者认领需求如果出现一次延期，可以申请交付计划变更一次，再次计划延期时间原则上不能超过原计划需求工作量的20%，如果出现再次延期，由sig组有权重新分配责任人或调整交付范围。
+
+  
+  ### 需求类issue各字段的要求
+- issue状态字段是跟踪管理issue重要的信息，需要在处理issue环节及时更新
+|   状态字段 | 负责人  | 描述  |
+| ------------ | ------------ | ------------ |
+|  待办 | 提交者  | 任何开发者都可以提交需求到社区，初始状态为待办 |
+|  已确认 |sig组   |由sig组指定责任人收集需求，并和提交者确认   |
+|  已分解 |sig组   |需求经过评审接纳后分解需求，组织需求分配责任人   |
+|  设计中 |需求责任人   | 按照设计要求输出设计文档  |
+|  开发中 |需求责任人   | 代码开发，本地验证，提交pr到社区，开发完成指定需求回归测试人员  |
+|  验收中 |测试   |由测试人员回归验收需求   |
+|  已完成 |测试   |经过测试验收后的需求   |
+|  已拒绝 |sig组   |经和提交者确认或PMC评审，此需求不接纳   |
+
+  
+
+
+

sig/sig-QA/代码门禁要求.md

+# OpenHarmony 代码门禁质量要求、活动定义及实践介绍
+
+    代码门禁的使用场景：当开发者完成一个issue（Feature、Task、Bug），准备提交PR合入开源主干，在代码合入主干前，会触发代码检视、代码门禁流水线，其中代码门禁负责检查待合入PR新增或者修改的所有文件是否达到质量要求。达到质量要求才允许合入开源主干；否则该PR需要开发者修订检查出来的问题，继续重复提交PR动作。
+    
+    注意：代码门禁的触发以issue为单位，支持一个Issue下面挂多个PR的情况，原因是研发中存在一个Issue单需要多人联合开发场景，或者说多个PR存在关联关系，为了避免代码门禁的重复构建或者PR间的相互依赖，需要以Issue为单位多PR提交后，再触发代码门禁执行。
+     
+    代码门禁的活动定义及实践：代码门禁活动主要分为流水线触发（码云触发流水线执行：webhook模式）、代码下载、构建、部署、测试几个步骤，可参考图-1；其中主要的检查项包含：编译检查、静态/安全/开源检查、敏感词/copyright扫描、部署、冒烟测试、功能测试；因为OpenHarmony涉及多型号开发板验证，为了提升门禁执行效率，使用了基于提交PR识别的精准构建和精准测试。门禁检查结果可以通过码云提交PR的评论区查看（参考图-2）或者直接访问Http://ci.openharmony.cn查看结果（参考图-3）。
+
+图-1：代码门禁的主要活动和实践
+
+![图一](figures/p1.png)
+
+图-2：在码云评论区可以直接查看代码门禁执行结果																							
+
+![图-2](figures/p2.png)
+
+图-3：OpenHarmony的Ci门户网站，可以直接访问Http://Ci.openharmony.cn ;查看代码门禁、每日版本构建的详细情况。可点击每笔记录，查看详情。
+
+![图-3](figures/P3.png)
+
+
+
+
+# 代码门禁的质量要求：包含检查项、规范、及操作指南
+
+      代码门禁的质量要求：涉及的PR提交代码等文件必须通过各项检查，才允许代码合入主干。
+      当前门禁检查项包含：编译告警（涉及多型号开发板及模拟器）、构建规范检查（鸿蒙构建规范）、CodeCheck（静态/安全/开源检查、敏感词/copyright扫描）、部署（烧录）、测试（冒烟测试和功能测试）4个部分，下面具体来说明每个部分的检查项及要求。
+
+## 编译告警 <a name="section20979554791"></a>
+
+    编译告警主要用于检查代码下载是否Ready(基线代码下载、PR代码获取)、编译环境是否Ready（prebuilds编译依赖工具、lfs二进制工具、node_modules、nodejs、build/lite等）、编译是否通过（全量编译、增量编译、缓存是否OK）、编译选项检查是否最优；
+    编译选项检查主要是针对C/C++语言编译选项或系统配置的检查，检查规范涉及语言选项、警告选项、安全选项、总体选项、代码生成选项、架构选项、优化选项、编译宏等。
+
+参考 [Openharmony 编译选项规范](Openharmony_Compile_Rule.md)    
+
+## 构建规范检查 <a name="section20979554791"></a>
+
+    为指导OpenHarmony的社区开发者开展构建工作，提升构建系统的可重复性、可维护性，提高构建质量，构建规范工作组分析总结了各种典型的构建问题，提炼相应的构建规则和建议，制订了规范，用于保障构建脚本的存放目录、文件格式、编写内容符合要求。 
+
+具体规范参考[Openharmony 构建规范](Openharmony_Build_Rule.md)    
+
+## CodeCheck检查 & 屏蔽
+
+#### CodeCheck检查
+      CodeCheck支持静态扫描、安全扫描、代码度量、开源合规、敏感词扫描、Copyright等检查服务。对于检测问题存在争议，需要和Committer确认，是否为问题或者工具告警在当前代码上下文为非问题。Committer确认问题不用修改，可直接在Ci门户网站登录，系统会提供屏蔽功能，允许Committer屏蔽该问题，以保障该问题不再重复检测出现。
+
+#####  工具及服务使用
+      CI门户：选择任意一个PR的CodeCheck检查结果（包括“通过”、“不通过"、“失败”，若结果为“失败”表示未获取到扫描结果，即不支持查看），进入到代码检查结果查看页面。具体如下。
+1、选择任意一个代码门禁CI流水线执行记录，进入详情查看页面
+![](figures/P4.png)
+
+2、点击CodeCheck检查结果，例如：”不通过“，进入代码检查详情页面
+![](figures/P5.png)
+
+      码云：从码云选择提交的PR（对应仓库下的Pull Requests），或从CI门户上选择任意一个PR进入详情后点击合入请求即跳转码云对应的PR，根据评论中start build的时间找到对应的合入记录，即可查看CodeCheck检查返回的结果。具体如下。
+
+1、选择任意一个PR的合入请求即可跳转码云对应的PR，如下
+码云入口：
+![](figures/P6.png)
+
+CI门户入口：
+![](figures/P7.png)
+
+2、根据评论中start build的时间找到对应的合入记录，即可查看CodeCheck检查返回的结果
+
+![](figures/P2.png)
+
+##### 静态扫描 
+支持通用&安全编程规范集成；支持C/C++、JAVA、JS。
+具体规则参考 [Openharmony 通用编码规范](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md) 
+
+##### 安全扫描
+支持C/C++、Java、JS语言安全编程规范的检查。
+具体规则参考[Openharmony 安全编码规范](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%B4%A1%E7%8C%AE%E4%BB%A3%E7%A0%81.md) 
+
+##### 代码度量
+支持单仓代码检查；支持代码行、重复率、重复文件数、函数数、圈复杂度总数统计和展示。
+
+
+##### 开源及第三方
+支持开源及第三方软件的源码文件、二进制文件扫描，提供风险扫描及评估能力。
+
+##### 敏感词扫描
+支持配置敏感词清单，输出文件名、路径名、文件内容中的敏感词扫描结果。
+
+
+##### Copyright
+支持基于文件夹、文件名、文件后缀配置Copyright规则，规则可以配置Copyright类型和逻辑。
+
+
+#### 屏蔽指导
+屏蔽操作主要针对一般以及上问题级别，未登录或者非代码仓的commiter用户无操作权限。当前的主要规则如下(黄区网络暂时无法屏蔽代码问题)：
+1、未解决问题可以修改为已忽略问题；
+2、已忽略问题可以修改为未解决问题；
+3、未解决问题和已忽略问题都无法修改已解决问题
+
+#####  单个问题状态修改
+根据过滤器查出出来的结果，选择问题，下拉菜单点击"已忽略"即可。
+![](figures/P8.png)
+
+#####  批量操作问题修改
+选择要修改的问题后点击 "批量操作"，设置修改后的问题状态为"已忽略"，然后“确认”即可。
+![](figures/P9.png)
+
+![](figures/P10.png)
+
+## 部署升级及测试
+      门禁流水线测试涉及的测试活动主要有部署升级、冒烟测试、功能测试、API看护测试。精准测试是对功能测试及API看护测试用例挑选后的精确测试，具体如下： 
+
+#### 冒烟测试
+
+      冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，关注的是阻塞型缺陷。
+      门禁冒烟测试用例是选择功能测试用例中level 0的用例，主要保障版本可以正常开关机，主功能可用，覆盖多种设备形态。
+
+#### 功能测试
+      功能测试是对产品的各功能模块进行验证，包含全量测试用例中level 0~5的用例。根据功能用例覆盖结果，测试产品是否达到各模块功能的质量要求。
+
+#### API看护测试 
+      根据代码仓与api头文件的关联关系，通过识别所提交的代码对代码仓头文件的修改，触发对应形态下自身代码仓的XTS用例的执行。
+
+#### 优化：精准构建&精准测试
+      根据代码仓与设备形态之间的关联关系，通过识别所提交的代码对代码仓文件的修改，触发对应形态下所修改的代码仓的TDD level0用例的执行。
+
+#### 代码门禁测试用例上线规则
+
+##### 门禁问题提单
+1、门禁用例问题第一时间转给第一责任人，经分析后，由第一责任人继续往下分解
+
+
+##### 门禁响应时间
+1、TDD 用例上线门禁后，定位出用例导致的测试失败，需要两小时内闭环
+
+##### 门禁用例下线
+1、用例问题两小时未解决的，需对应的责任田即时下线，不影响后续的门禁
+
+##### 门禁用例上线
+1、用例重新上线或者新用例上线，需要责任人提供两天以上的稳定报告并知会我们（门禁看护人），
+2、流水线这边压测48小时后才可重新上线
\ No newline at end of file

sig/sig-QA/架构设计原则.md

+### 架构设计目标
+从技术架构层面讲需要满足以下目标：
+- **弹性：**架构要支持高度组件化，各子系统/功能模块/子功能模块均能实现独立编译。可适应从高端手机（如：8核SOC@3GHz/16GB RAM/512GB ROM）到手环、IoT模块(如：单核MCU@50MHz/128KB RAM/64MB ROM)等硬件配置差异巨大的多种终端，以及将来8~10年内可能出现的新类型终端。
+- **可分布性：**系统提供的各种软件硬件服务，具有非集中式服务架构，可以在同一分布式系统下的多个终端上形成非对称的分布式计算。同时系统提供分布式用户程序框架，使应用程序同样具有可分布性。可分布式性一个隐含的需求是对跨版本，跨设备的较长周期的兼容性要求。
+- **可演进性：**可适应未来8~10年可能出现的新技术带来的新业务模式，可实现老特性的逐步淘汰和新特性的平滑上线。
+- **生态友好性：**可高效支持三方开发北向应用和对南向设备，并允许三方设备厂家开发扩展能力获得足够的商业利益，同时确保系统生态的完整性和一致性。
+- **可重构性：**支持系统可局部重构。从项目基本需求考虑，由于存在生态环境变化、产品业务策略变化、业界技术趋势变化等诸多不确定因素，因此需要系统架构支持随时存在局部重构的可能性。为了保证局部重构的工作量尽可能小，需要子系统/功能模块/子功能模块均可支持可独立重构，每个子功能模块的代码规模要求不大于2万行。
+- **可用性：**可用性是指系统处在可工作状态的时间的比例，单设备系统异常每千小时不大于0.2次，分布式系统异常每千小时不大于2次。
+- **流畅性：**最终目标是向用户提供流畅的业务体验，用户交互设计在架构上需要保障处理时长可控。
+- **安全性：**构建用户隐私数据保护的安全体系与分级，隔离的安全防御体系。
+### 架构设计原则
+- **用户体验优先原则：**面向业务获取和使用场景，构建实时、按需、在线、自助、社区化、方便易用的用户体验；
+- **UX交互优先原则：**用户交互相关服务/组件优先获取足够系统资源，软件资源或硬件资源，保障用户体验的高流畅性。
+- **隐私保护与安全原则：**构建最小权限、纵深防御、最小公共化、权限分离、不轻信、开放设计、完全仲裁、失效安全、保护薄弱环节、安全机制经济性、用户接受度以及加强隐私保护的安全体系，确保系统、网络和数据的机密性、完整性、可用性、可追溯。在各项设计目标发生冲突的情况下，隐私保护必须优先满足。
+- **生态开放原则：**面向生态场景，按需开放平台设施、中间件、数据、业务逻辑、UI等能力，构建开放生态，支持分层、远程、自动、自助、简单高效地完成定制、集成、第三方应用开发。
+- **跨多设备原则：**同类设备采用统一技术架构，技术框架和技术方案，支持一次开发支持所有设备，尽可能保持一致的业务体验。充分发挥不同设备的优势功能点，通过相关设备弥补自身设备的劣势功能点，设备间支持快速能力发现，能力互相调用，协同完成业务过程中对用户和开发者尽量无感知。
+- **模块解耦原则：**对业务进行抽象建模，业务数据与业务逻辑解耦，软件和硬件解耦，平台和产品解耦，系统各部件间解耦。
+- **服务化/组件化原则：**以服务、数据为中心，构建服务化、组件化架构，具备灵活、按需组合的能力。
+接口隔离及兼容性原则：通过接口隐藏服务/组件的实现细节，服务/组件间只能通过接口进行交互，接口契约化、标准化，跨版本和跨设备兼容；热点服务/组件长期支持可独立演进、独立发布、独立升级；服务或组件自治，可管、可控、可测、可维、关键服务/组件要求故障可自愈。
+- **高性能低功耗原则：**在满足用户业务体验的前提下，功耗要做到最低；在同样功耗条件下，性能要做到最高。性能和功耗高度统一，不在无谓的性能上浪费功耗，也不在为了节省功耗而牺牲用户体验。
+- **高效开发原则：**创建支持迭代、增量、持续交付的架构，支持部件独立开发、自动化编译构建、测试、集成验证，并易于高效修改和持续优化；支持开发组织小型化、扁平化，支持小团队独立高效并行开发。
+- **开源引用原则：**充分利用业界优秀的开源实践，不重复造轮子。需要进一步说明的是，每一个架构设计原则的守护都要付出一定的代价，也会带来相应的收益。甚至部分原则间存在不可避免的冲突和矛盾，上述架构原则需要综合考虑，整体权衡，不可孤立的强调一个而忽视另一个。权衡时针对具体问题具体分析，权衡的过程也是在某一个特定场景下的设计原则的优先级选择过程。
\ No newline at end of file

sig/sig-QA/版本质量要求.md

+| 分类说明  | Canary版本  |Beta版本   |正式/LTS版本   |
+| :------------ | :------------ | :------------ | :------------ |
+|能力目标   |尝鲜版本，支持厂商联调开发和验证   |基本功能稳定、支持厂商联调开发和验证   |功能稳定，通过专项测试、支持三方厂商商业化集成   |
+| 发布周期  |事件驱动   |2个月   |半年/年度   |
+| 获取渠道  |每日构建流水线   | XXX  | XXX  |
+
+
+
+|  质量要求小类 |Canary版本   |Beta版本   |正式版/LTS版本| 说明 | 
+| :------------ | :------------ | :------------ | :------------ | :------------ |
+| 社区门禁&流水线检查| 通过  |通过   |通过   |  |
+| 冒烟测试通过率 | >95%  |100%   | 100%  |  |
+| XTS测试通过率| NA  |100%   |100%   |   |
+| 测试用例通过率|NA   |>95%   |100%   |   |
+| 测试用例自动化测试比例  |NA   |牵引80%但不阻塞   |80%   |   |
+| 安装部署  |NA   |通过   |通过   | 基于社区开源板部署|
+| 升级（社区公版）|NA   |NA   |通过   |  满足社区已发布的历史公版升级 |
+| 性能  | NA  |满足Beta基线   |满足基线   | 基于社区开发板的性能规格  |
+| 功耗  | NA  |满足Beta基线   |满足基线   | 基于社区开发板的功耗规格  |
+| 安全  | NA  |通过   |通过   |   |
+| 稳定性  |NA |满足Beta基线   |满足基线   |   |
+| ROM/RAM空间（基于社区开源板）|NA |满足Beta基线   |满足基线   |   |
+| 兼容性（基于开源板和社区PCS文档） |NA |满足基线   |满足基线   | 基于开源板和社区PCS文档  |
+| 遗留问题   |无关键阻塞问题|无安全红线问题、无关键阻塞问题| 无安全红线问题、无关键阻塞问题  |   |
+| 资料   |通过（Canary配套）| 通过（Beta配套）   | 通过（正式版）|  |