mirror of
https://gitee.com/openharmony/community
synced 2024-11-30 02:10:51 +00:00
parent
a4856c76d0
commit
fd96af75fa
@ -30,7 +30,7 @@ PMC 例会 2022-04-21
|
||||
| ---- | ------------------------------- | ---------------------------------------- |
|
||||
| No64 | 欧洲侧发现的OpenHarmony社区问题更新 | 结论:<br>1)多个工具链问题:欢迎社区对clang工具链版本升级做贡献。Oniro团队提案的 clang 14 demo 与 编译运行时sig 对接讨论。负责人:刘建宇,安光霖。完成时间: 下一个release版本前 <br>2)对齐OpenHarmony和Oniro的开源软件BoM列表所应该包含的信息,确保符合OpenChain规定。负责人:刘建宇 , 王意明。完成时间:2022年5月12日 <br>3)三方组件重复fork的问题:原则上如果能归一版本需要尽量归一,如由于场景不同确实需要不同版本,可另外审视允许。 负责人:各组件仓committer。暂无完成时间。 <br>4)二进制包开源和构建指导: 目前暂无进展,但是需要明确节奏。建议作为遗留问题定期追踪。负责人:刘建宇 , 吴勇辉。ddl:定期追踪。 <br>5). release版本版本号:以release sig为准。 |
|
||||
| No65 | OpenHarmony代码仓分组下载管理方案 | 结论:<br>同意按照类别下载代码,同意开发板、产品以及CI工程名称统一的规则。<br>遗留问题:<br>1)支持按照类别下载代码后,需确定门禁看护策略。 责任人:王意明,完成时间:2021年05月13日<br>2)根据方案,刷新repo仓组织方式。 责任人:张小田,完成时间2022年4月30日.<br> 3)已支持的开发板建议根据规则逐步整改。 责任人:鲍国涛,完成时间:2022年7月30日 |
|
||||
| No66 | 申请成立OpenCVSIG组 | 结论:<br>建议进一步分析清楚两个问题,再进一步审视是否成立独立Sig。<br>1)OpenCV的适配哪些未来进入上游,哪些需要在openharmony仓库上承载<br>2)从职责上分析与图形Sig的差异。责任人:巴延兴,完成时间:2022年05月31日 |
|
||||
| No66 | 申请成立OpenCV SIG组 | 结论:<br>建议进一步分析清楚两个问题,再进一步审视是否成立独立Sig。<br>1)OpenCV的适配哪些未来进入上游,哪些需要在OpenHarmony仓库上承载<br>2)从职责上分析与图形Sig的差异。责任人:巴延兴,完成时间:2022年05月31日 |
|
||||
| No67 | 官网呈现PR、issue、sig、commits等数据统计规则 | 结论:<br>1)同意《OpenHarmony官网呈现数据统计规则》统计范围、统计接口、统计输出格式等规则。<br>2)同意PR数可以代表代码活跃性度,官网去掉commit数字展示。<br>3)同意委托祝尚元月中、月末周期性统计,QA SIG审核数据,交与基础设施组官网更新。 |
|
||||
| No68 | OH Tech Day 情况通报 | 结论:<br>议题12选4。通过2轮总体组评审,2轮PMC评审,4个议题已经确认,议题演讲人与标题已确认,进展顺利。活动2022年4月25日进行。 |
|
||||
| No69 | 社区代码贡献之星和社区代码卓越贡献单位颁奖设计的汇报 | 结论:<br>同意社区代码贡献之星和社区代码卓越贡献单位颁奖颁奖。<br>1)对于颁奖的标准,PMC建议同时考虑主仓代码度量结果和Community及Docs度量结果,采取权重相加的办法。<br>2)本次颁奖中,建议不要在奖项中显式化具体排名,可以采用TOP X的方式。3)对于本次颁奖,如果简单相加与单独代码度量结果一致,不影响颁奖受众的范围,则可直接采用名单颁奖;如果结果不一致,需要分析研究业界的权重惯例,按照惯例赋予代码及文档以权重。 |
|
||||
|
@ -12,17 +12,17 @@
|
||||
|
||||
图-1:代码门禁的主要活动和实践
|
||||
|
||||
![图一](figures/p1.png)
|
||||
![图-1](figures/p1.png)
|
||||
|
||||
其中主要的检查项包含:编译检查、静态/安全/开源检查、敏感词/copyright扫描、部署、冒烟测试、功能测试。由于OpenHarmony涉及多型号开发板验证,为了提升门禁执行效率,基于提交PR识别精准构建和精准测试。
|
||||
|
||||
门禁检查结果可以通过码云提交PR的评论区查看(参考图-2)或者直接访问Http://ci.openharmony.cn查看结果(参考图-3)。
|
||||
门禁检查结果可以通过码云提交PR的评论区查看(参考图-2)或者直接访问[http://ci.openharmony.cn](http://ci.openharmony.cn)查看结果(参考图-3)。
|
||||
|
||||
图-2:在码云评论区可以直接查看代码门禁执行结果
|
||||
|
||||
![图-2](figures/p2.png)
|
||||
|
||||
可以直接访问Http://Ci.openharmony.cn ,查看代码门禁、每日版本构建的详细情况。可点击每笔记录,查看详情。
|
||||
可以直接访问[http://ci.openharmony.cn](Http://ci.openharmony.cn) ,查看代码门禁、每日版本构建的详细情况。可点击每笔记录,查看详情。
|
||||
|
||||
图-3:OpenHarmony的Ci门户网站
|
||||
|
||||
@ -37,7 +37,7 @@
|
||||
|
||||
### 编译告警 <a name="section20979554791"></a>
|
||||
|
||||
编译告警主要用于检查代码下载是否Ready(基线代码下载、PR代码获取)、编译环境是否Ready(prebuilds编译依赖工具、lfs二进制工具、node_modules、nodejs、build/lite等)、编译是否通过(全量编译、增量编译、缓存是否OK)、编译选项检查是否最优;
|
||||
编译告警主要用于检查代码下载是否Ready(基线代码下载、PR代码获取)、编译环境是否Ready(prebuilts编译依赖工具、lfs二进制工具、node_modules、nodejs、build/lite等)、编译是否通过(全量编译、增量编译、缓存是否OK)、编译选项检查是否最优;
|
||||
编译选项检查主要是针对C/C++语言编译选项或系统配置的检查,检查规范涉及语言选项、警告选项、安全选项、总体选项、代码生成选项、架构选项、优化选项、编译宏等。
|
||||
|
||||
参考 [OpenHarmony编译规范](编译规范.md)
|
||||
@ -54,7 +54,7 @@
|
||||
CodeCheck支持静态扫描、安全扫描、代码度量、开源合规、敏感词扫描、Copyright等检查服务。对于检测问题存在争议,需要和Committer确认,是否为问题或者工具告警在当前代码上下文为非问题。Committer确认问题不用修改,可直接在Ci门户网站登录,系统会提供屏蔽功能,允许Committer屏蔽该问题,以保障该问题不再重复检测出现。
|
||||
|
||||
##### 工具及服务使用
|
||||
CI门户:选择任意一个PR的CodeCheck检查结果(包括“通过”、“不通过"、“失败”,若结果为“失败”表示未获取到扫描结果,即不支持查看),进入到代码检查结果查看页面。具体如下。
|
||||
CI门户:选择任意一个PR的CodeCheck检查结果(包括“通过”、“不通过”、“失败”,若结果为“失败”表示未获取到扫描结果,即不支持查看),进入到代码检查结果查看页面。具体如下。
|
||||
1、选择任意一个代码门禁CI流水线执行记录,进入详情查看页面。
|
||||
![](figures/p4.png)
|
||||
|
||||
|
@ -17,7 +17,7 @@ Basic Software Services includes the following sub-systems:
|
||||
|DFX System|Design-for-Test, Design-for-Reliability and Design-for-Manufacturing|
|
||||
|Event Notification System|Manage system and application notifications|
|
||||
|Resource Management System|Manage system resources, including CPU, IO and memory,Background task manager,Workscheduler|
|
||||
|Distributed Scheduling System|Scheduing Abilities in Open Harmony distributed network|
|
||||
|Distributed Scheduling System|Scheduling Abilities in Open Harmony distributed network|
|
||||
|Account Management System|Manage user accounts for Open Harmony|
|
||||
|Barrier Free System|Provide barrier free common capabilities for Open Harmony|
|
||||
|Miscellaneous Software System|Provide some miscellaneous services for Open Harmony|
|
||||
|
@ -34,7 +34,7 @@
|
||||
[@neeen](https://gitee.com/neeen)
|
||||
|
||||
### Committers列表
|
||||
- [@duangavin123](https://gitee.com/duangavin123)
|
||||
- [@duangavin123](https://gitee.com/duangavin123_admin)
|
||||
- [@RayShih](https://gitee.com/RayShih)
|
||||
- [@Peter_1988](https://gitee.com/Peter_1988)
|
||||
|
||||
|
@ -6,7 +6,7 @@ Note: The content of this SIG follows the convention described in OpenHarmony's
|
||||
## SIG group work objectives and scope
|
||||
|
||||
### work goals
|
||||
SIG aims to build a software and hardware ecosystem around openharmony, work with software and hardware partners in the field of education to solve the high-frequency pain points in the scene of educational data collection, jointly formulate educational exclusive operating system and data collection standards, help the independent innovation of the education industry, and promote the rapid development of educational informatization on openharmony in the north-south direction.
|
||||
SIG aims to build a software and hardware ecosystem around OpenHarmony, work with software and hardware partners in the field of education to solve the high-frequency pain points in the scene of educational data collection, jointly formulate educational exclusive operating system and data collection standards, help the independent innovation of the education industry, and promote the rapid development of educational informatization on OpenHarmony in the north-south direction.
|
||||
|
||||
**Donate the ability components related to data collection to form the factual standard for data collection of educational information**.
|
||||
|
||||
|
@ -7,7 +7,7 @@
|
||||
|
||||
### 工作目标
|
||||
1. 做系统级公共渲染组件,对外可提供两套接口,一个用于系统自身,一个用于APP
|
||||
2. 针对openharmony多平台多内核特性,提供不同级别的渲染能力,包括:
|
||||
2. 针对OpenHarmony多平台多内核特性,提供不同级别的渲染能力,包括:
|
||||
* 不同的js引擎切换
|
||||
* 不同的H5标准支持
|
||||
* 不同的拓展能力支持(基础渲染、webgl、webRtc、音视频等)
|
||||
|
@ -1,4 +1,4 @@
|
||||
# SIG Relase
|
||||
# SIG Release
|
||||
简体中文 | [English](./sig_release.md)
|
||||
|
||||
说明:本SIG的内容遵循OpenHarmony的PMC管理章程 [README](/zh/pmc.md)中描述的约定。
|
||||
@ -23,7 +23,7 @@ openHarmony社区在每个发行版正式发布评审会议之前,通过邮件
|
||||
| 1 | 社区版本发布评审 | 评审入口条件检查 | 在正式发布评审会之前,对于评审入口条件进行检查,需社区代码工具告警清零、社区版本集成测试活动完成、无关键阻塞问题遗留、配套资料完成。 | SIG-QA |
|
||||
| 2 | 社区版本发布评审 | 组织社区版本发布评审| 正式组织社区版本发布评审会,正式评委包含:测试SIG、QA团队、法务、配置管理团队、版本发布团队、基金会基金会 | SIG-release |
|
||||
| 3 | 社区版本发布评审 | 社区版本版本包发布 | 社区版本分支TAG归档,上传华为云,版本获取链接更新并验证(含SDK) | SIG-社区构建 |
|
||||
| 4 | 社区版本发布评审 | 社区版本发布后用户验证 | 针对最终发布版本的验证,确保与计划发布版本一致,含两种方式: - Repo拉取源码获取、编译烧录、亮屏;- Docker环境下的编译、烧录、亮屏 | SIG-releas(基金会参与) |
|
||||
| 4 | 社区版本发布评审 | 社区版本发布后用户验证 | 针对最终发布版本的验证,确保与计划发布版本一致,含两种方式: - Repo拉取源码获取、编译烧录、亮屏;- Docker环境下的编译、烧录、亮屏 | SIG-release(基金会参与) |
|
||||
| 5 | 社区版本发布评审 | Release notes发布社区 | Release notes发布社区 | SIG-release |
|
||||
| 6 | 社区版本发布评审 | 版本发布社区邮件推送 | 版本发布社区邮件推送 | SIG-release |
|
||||
| 7 | 社区版本发布评审 | 版本发布社区公告 | 版本发布社区公告 | SIG-社区构建 |
|
||||
|
Loading…
Reference in New Issue
Block a user