October 2020 - Tc - mailweb.openeuler.org

openEuler社区QA测试团队双周会议纪要（2020/10/28）
by liyongqiang (H) 29 Oct '20

29 Oct '20

openEuler社区QA测试团队双周会议时间： 16:00-17:30 2020/10/28 参会者：kuhnchen18 lutianxiong speacher lemon-higgins rigorous Charlie_li 会议纪要人: Charlie_li 分类遗留问题及其他进展状态责任人社区QA团队治理与运营 src_openeuler组织下申请制品仓 10/28:打为一个包test-tools，用例代码通过工具进行下载，不会单独打包用例包；不会放入ISO，可能放入epol 10/14:openEuler相关的test-tools/integration-test两个仓已经建立完成；包发布方式需和包管理团队对齐 Running Charlie_li/kuhnchen18 测试代码合规检查(shell/python) 10/28:shell检查结果需要基础设施切换个服务 10/14:python和java码云已支持；shell也已经对接，当前是默认配置检查； Running Charlie_li/kuhnchen18/ lemon-higgins 集成类测试能力开源 10/28:代码开源范围评审中，争取月底前完成开源 10/14:单包加固/系统用户集成/新特性的月底前开源 8/12:包差异代码评审后还需进一步整改 7/29:容器基本功能开源完成；包差异整改80% 7/15:容器基本功能已完成整改，待开源；包差异对比工具整改进行60% 7/1:AT用例已完成检视，rpm包差异对比工具和容器基本功能用例整改中 Running Charlie_li/lemon-higgins 内核和编译器提供指导文档说明如何使用内核LTP及gcc相关开源测试套 10/28:文档已编写完成，待PR合入 8/12:计划本周搞定 7/29:内核LTP的完成编写，之前由于蓝云网络问题，未上传，待提交PR 7/15:编译器指导文档已开源；内核LTP的完成编写，待提交PR 7/1:蓝云已提供，LTP待提交文档，GCC本周完成 Running rigorous 社区QA测试流程及指导文档编写 10/28:虚拟化相关文档以blog的方式进行呈现； 10/14:虚拟化相关文档已写完，待开放到码云 8/12: 虚拟化相关文档已完成50% Running Charlie_li/ kuhnchen18 社区issue提单及处理规范 10/28: issue模板及issue处理流程文档编写中 10/14:发布issue提单指导手册和issue处理规范 Running Charlie_li 版本测试暑期2020活动 10/28:已结项 10/14:学生课题已提交结项报告，本周进行验收 7/29:一个学生已完成测试方案设计,待和学生对齐； 7/15:暑期活动学生已开学，进展有些慢，线下和学生单点沟通； 7/1:暑期2020活动lrzsz、mysql加固已有学生报名，待深入沟通 Close Charlie_li 高优先级组件包质量加固 10/28:自动化率提升中，加固暂未投入 8/12:Euleros完成7个包的加固；openEuler完成8个包的加固 7/29:已完成6个包的加固，openEuler版本测试中会在执行时覆盖 Pause Lutianxiong/lemon-higgins 缺陷分析 10/28:暂未开始 9/23: 完成9月份的issue分析并在openEuler 20.09版本中补充相应测试用例 8/12:暂无进展 7/15:缺陷分析模板已完成初步评审，先运作，有其它建议再补充；每月例行开展一次，李永强统一整理外部问题作为输入提供给其它领域进行分析 Running Charlie_li 问题回归策略 10/14:状态为“已完成”经过验证已解决的改完“已验收” 8/12:7月份最新的问题单已完成回归确认 7/15:各领域owner优先处理330后状态是“已完成”的缺陷；输入是严志华整理的issue表格 Close Charlie_li/speacher/rigorous/lemon-higgins/ltx

1 0

【会议纪要】//答复: 【明日例会议题】openEuler Release-Management SIG meeting Time: 2020-10-28 9:30-11:30
by Jiangyumin (Jimmy) 28 Oct '20

28 Oct '20

Release-Management SIG 组例会会议纪要（时间：2020-10-28 9:30-11:30）：议题一：openEuler社区版本分支管理规范初稿讨论 1、 openEuler 20.03 LTS NEXT分支将作为 20.03 LTS SP版本的开发分支进行特性开发合入。 2、 20.03 LTS SP1版本发布后，CVE漏洞与BUG修复需要同时在 20.03 LTS、20.03 LTS NEXT、20.03 LTS SP1三个分支合入。 3、 OpenEuler 版本分支管理规范稿在release sig 组发起讨论后最终定稿。议题二： kernel切换计划与后续的版本配套计划 1、 kernel计划本周v5.10-rc1版本发布后，启动在master分支上的切换，并最终5.10正式发布后（预计12月下旬），配套openEuler 21.03版本。 2、 kernel 将在openEuler 20.03 LTS SP2版本做较大的改动合入，可能会引起兼容性问题，需要kernel分析影响后在社区发起讨论，最终在TC决策。 3、 kernel是否单独建仓，在过程迭代中发布独立版本供开发者快速获取尝试，待进一步讨论在TC决策。议题三：树莓派镜像添加到树莓派官方第三方系统镜像工作进展 1、树莓派关于openEuler在使用与运营数据需要补充在全球的使用情况与发展趋势，运营数据可从运营团队获取。 2、 Jason文件的存放目录需要与运营负责人马全一讨论后确定。 3、对于密码设置的策略需要与安全委员会成员沟通后，根据不同场景给出方案，在TC进行决策。议题四：openEuler 20.03 LTS SP1 冻结需求 1、 openEuler 20.03 LTS SP1需求已冻结，需求列表在release sig组进行公布。 2、后续openEuler 版本需求收集除了在社区上进行公示外，建议与每个SIG 的maintainer再进一步确认，对于有市场诉求SIG组无法支持的，建议上TC决策。发件人: Jiangyumin (Jimmy) 发送时间: 2020年10月27日 16:22 收件人: release(a)openeuler.org; dev(a)openeuler.org 抄送: openEuler-tc <tc(a)openeuler.org>; Hufeng (Solar, Euler) <solar.hu(a)huawei.com>; Xiexiuqi <xiexiuqi(a)huawei.com>; '方亚芬' <yafen(a)iscas.ac.cn> 主题: 【明日例会议题】openEuler Release-Management SIG meeting Time: 2020-10-28 9:30-11:30 明日Release sig 组例会议题如下： 1、openEuler 20.03 LTS SP1 冻结需求 ---- 胡峰 2、kernel切换计划与后续的版本配套计划 --- 谢秀奇 3、树莓派镜像添加到树莓派官方第三方系统镜像工作进展 --- 方亚芬发件人: Jiangyumin (Jimmy) [mailto:jiangyumin@huawei.com] 发送时间: 2020年10月26日 10:38 收件人: release(a)openeuler.org<mailto:release@openeuler.org>; dev(a)openeuler.org<mailto:dev@openeuler.org> 抄送: openEuler-tc <tc(a)openeuler.org<mailto:tc@openeuler.org>> 主题: [Release] 【议题收集】【Meeting Notice】openEuler Release-Management SIG meeting Time: 2020-10-28 9:30-11:30 Topic 【议题收集】Release-management sig组例会 (可直接回复此邮件申报议题） Time 2020-10-28 9:30-11:30((UTC+08:00)Beijing) --- 会议信息 --- 会议id: 96457420049 会议链接：https://zoom.us/j/96457420049?pwd=di95MnJaUU1sNmxFQWMrNjBMZFBEZz09 --- 会议纪要归档 --- Meeting Record： https://gitee.com/openeuler/release-management/wikis

1 0

答复: 关于firefox（79.0）依赖gcc(7.3)编译问题的讨论纪要
by guoge (A) 28 Oct '20

28 Oct '20

建议方案1，在gcc中合入bugfix 在firefox的spec文件中是否需要关闭-fstack-clash-protection建议再进一步分析，一般认为这里可能有潜在的代码隐患，最好的方式是不要去关闭一个安全检查掩耳盗铃，而是通过修改代码修复安全问题发件人: Zhanghaijian (A) 发送时间: 2020年10月28日 10:47 收件人: gaojianxing <gaojianxing(a)huawei.com>; xiasenlin <xiasenlin1(a)huawei.com>; guoge (A) <guoge1(a)huawei.com>; qiaopeixin <qiaopeixin(a)huawei.com> 抄送: Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com> 主题: RE: 关于firefox（79.0）依赖gcc(7.3)编译问题的讨论纪要目前就3个方案可以讨论： 1、关闭选项-fstack-clash-protection，回合bugfix patch。 2、关闭选项-fstack-clash-protection，升级gcc7.5。 3、升级gcc9.3。方案3影响非常大，不建议。 -------------------------------------------------- 章海剑 Zhang Haijian Mobile: +86-15958121590<tel:+86-15958121590> Email: z.zhanghaijian(a)huawei.com<mailto:z.zhanghaijian@huawei.com> 发件人：Zhanghaijian (A) <z.zhanghaijian(a)huawei.com<mailto:z.zhanghaijian@huawei.com>> 收件人：gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>>;xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>>;guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>;qiaopeixin <qiaopeixin(a)huawei.com<mailto:qiaopeixin@huawei.com>> 抄送：Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>> 时间：2020-10-28 10:35:47 主题：RE: 关于firefox（79.0）依赖gcc(7.3)编译问题的讨论纪要编译选项“-fstack-clash-protection”，我们并没有说可以去掉，去掉会降低安全性，如果要去掉，需要firefox负责人自己评估 -------------------------------------------------- 章海剑 Zhang Haijian Mobile: +86-15958121590<tel:+86-15958121590> Email: z.zhanghaijian(a)huawei.com<mailto:z.zhanghaijian@huawei.com> 发件人：gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>> 收件人：xiasenlin <xiasenlin1(a)huawei.com<mailto:xiasenlin1@huawei.com>>;guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>;Zhanghaijian (A) <z.zhanghaijian(a)huawei.com<mailto:z.zhanghaijian@huawei.com>>;qiaopeixin <qiaopeixin(a)huawei.com<mailto:qiaopeixin@huawei.com>> 抄送：Zhangtao (zhangtao, AX) <zhangtao221(a)huawei.com<mailto:zhangtao221@huawei.com>> 时间：2020-10-28 10:26:09 主题：答复: 关于firefox（79.0）依赖gcc(7.3)编译问题的讨论纪要 Firefox 79.0 依赖gcc（7.3.0）编译问题进展在编译器组兄弟的协助下，对于firefox 79.0编译不通过问题定位如下：问题1：firefox79.0 中 RefPtr.h 中相关构造函数问题，是gcc的一个bug引起的，Patch：https://github.com/gcc-mirror/gcc/commit/57b9… 可以解决此问题；问题2：编译选项“-fstack-clash-protection”gcc 7.3.0 不识别问题，这个参数编译器提供的一个堆栈冲突缓解的选项，用于提高安全性的。注（编译器组兄弟说是可以去掉）问题3：编译选项“-m64”参数不识别问题，-m64是x86 64位应用编译选项，m64选项设置int为32bits及long、指针为64 bits，为AMD的x86 64架构生成代码。在Arm64平台无法支持，arm64 对应的选项为：-mabi=lp64 方案选择： gcc openEuler-20.03-LTS-Next、openEuler-20.03-LTS版本需要合入C++ PR/81589补丁；在firefox的spec文件强行将默认的-fstack-clash-protection编译参数去除，注（只在openEuler-20.03-LTS-Next、openEuler-20.03-LTS）分支中移除，对arm64版本-m64参数更换为-mabi=lp64。发件人: xiasenlin 发送时间: 2020年10月27日 15:30 收件人: gaojianxing <gaojianxing(a)huawei.com<mailto:gaojianxing@huawei.com>>; guoge (A) <guoge1(a)huawei.com<mailto:guoge1@huawei.com>>; Zhanghaijian (A) <z.zhanghaijian(a)huawei.com<mailto:z.zhanghaijian@huawei.com>>; qiaopeixin <qiaopeixin(a)huawei.com<mailto:qiaopeixin@huawei.com>> 主题: 关于firefox（79.0）依赖gcc(7.3)编译问题的讨论纪要关于firefox（79.0）依赖gcc(7.3)编译问题的讨论纪要 1. 原始问题： firefox基于当前版本的gcc编译失败 2. 原因分析： firefox（79.0）需要智能指针特性，但是gcc7.3不支持（7.5及之后的版本是支持的） 3. 当前进展：尝试依赖gcc7.5编译firefox（79.0），在强制关闭firefox中的-fstack-clash-protection选项后可以编译成功。 4. 下一步计划：对比7.3到7.5之间的commit，找到能在gcc7.3上让firefox编译成功的patch。 5. 风险：短时间内找到有风险，每次尝试gcc上打patch之后编译新的二进制后重编firefox一次需要2h。 6. 可能的最终策略：本次的firefox是在LTS-NEXT分支，为SP1做准备，如果月底解决不掉当前的编译问题，firefox需要移出分支。

2 1

Re: TC 议题申报：sig-Java构建Nexus私服申请Nexus Pro(Nexus Professional)版本评估
by 董德平 27 Oct '20

27 Oct '20

构建Nexus私服目的：加速maven构件(Artifact)访问；安全性检查；维护社区内部构件(Artifact)；目前选用Nexus3版本，但存在商业版Nexus3 Pro(Nexus Professional) 和开源版Nexus3 OSS(Nexus Open Source)两个版本，Nexus3 OSS不支持HA，不能搭建集群，而Nexus3 Pro版本在HA（High Availability）和安全检查（Health Check）等方面的feature更加完善，因此希望能申请Nexus Pro版本。参考资料：各版本feature对比：repository-manager-feature-matrix Pro版本特性的详细说明：Repository Manager Pro Features ------------------ 原始邮件 ------------------ 发件人: "Jiangyumin (Jimmy)" <jiangyumin(a)huawei.com>; 发送时间: 2020年10月26日(星期一) 上午10:37 收件人: "release(a)openeuler.org"<release(a)openeuler.org>;"dev(a)openeuler.org"<dev(a)openeuler.org>; 抄送: "openEuler-tc"<tc(a)openeuler.org>; 主题: [Tc] ��ռ��Meeting Notice��openEuler Release-Management SIG meeting Time: 2020-10-28 9:30-11:30 Topic 【议题收集】Release-management sig组例会 (可直接回复此邮件申报议题） Time 2020-10-28 9:30-11:30((UTC+08:00)Beijing)     --- 会议信息 --- 会议id:    96457420049 会议链接：https://zoom.us/j/96457420049?pwd=di95MnJaUU1sNmxFQWMrNjBMZFBEZz09     --- 会议纪要归档 --- Meeting Record： https://gitee.com/openeuler/release-management/wikis  

1 0

Re: TC 议题申报：sig-Java构建Nexus私服申请Nexus Pro(Nexus Professional)版本评估
by 董德平 27 Oct '20

27 Oct '20

构建Nexus私服目的：加速maven构件(Artifact)访问；安全审核；维护社区内部构件(Artifact)；目前选用Nexus3版本，但存在商业版Nexus3 Pro(Nexus Professional) 和开源版Nexus3 OSS(Nexus Open Source)两个版本，Nexus3 OSS不支持HA，不能搭建集群，而Nexus3 Pro版本在HA（High Availability）和安全检查（Health Check）等方面的feature更加完善，因此希望能申请Nexus Pro版本。参考资料：各版本feature对比：repository-manager-feature-matrix Pro版本特性的详细说明：Repository Manager Pro Features ------------------ 原始邮件 ------------------ 发件人: "Jiangyumin (Jimmy)" <jiangyumin(a)huawei.com>; 发送时间: 2020年10月26日(星期一) 上午10:37 收件人: "release(a)openeuler.org"<release(a)openeuler.org>;"dev(a)openeuler.org"<dev(a)openeuler.org>; 抄送: "openEuler-tc"<tc(a)openeuler.org>; 主题: [Tc] ��ռ��Meeting Notice��openEuler Release-Management SIG meeting Time: 2020-10-28 9:30-11:30 Topic 【议题收集】Release-management sig组例会 (可直接回复此邮件申报议题） Time 2020-10-28 9:30-11:30((UTC+08:00)Beijing)     --- 会议信息 --- 会议id:    96457420049 会议链接：https://zoom.us/j/96457420049?pwd=di95MnJaUU1sNmxFQWMrNjBMZFBEZz09     --- 会议纪要归档 --- Meeting Record： https://gitee.com/openeuler/release-management/wikis  

1 0

【议题收集】【Meeting Notice】openEuler Release-Management SIG meeting Time: 2020-10-28 9:30-11:30
by Jiangyumin (Jimmy) 27 Oct '20

27 Oct '20

Topic 【议题收集】Release-management sig组例会 (可直接回复此邮件申报议题） Time 2020-10-28 9:30-11:30((UTC+08:00)Beijing) --- 会议信息 --- 会议id: 96457420049 会议链接：https://zoom.us/j/96457420049?pwd=di95MnJaUU1sNmxFQWMrNjBMZFBEZz09 --- 会议纪要归档 --- Meeting Record： https://gitee.com/openeuler/release-management/wikis

2 1

【明日例会议题】openEuler Release-Management SIG meeting Time: 2020-10-28 9:30-11:30
by Jiangyumin (Jimmy) 27 Oct '20

27 Oct '20

明日Release sig 组例会议题如下： 1、openEuler 20.03 LTS SP1 冻结需求 ---- 胡峰 2、kernel切换计划与后续的版本配套计划 --- 谢秀奇 3、树莓派镜像添加到树莓派官方第三方系统镜像工作进展 --- 方亚芬发件人: Jiangyumin (Jimmy) [mailto:jiangyumin@huawei.com] 发送时间: 2020年10月26日 10:38 收件人: release(a)openeuler.org; dev(a)openeuler.org 抄送: openEuler-tc <tc(a)openeuler.org> 主题: [Release] 【议题收集】【Meeting Notice】openEuler Release-Management SIG meeting Time: 2020-10-28 9:30-11:30 Topic 【议题收集】Release-management sig组例会 (可直接回复此邮件申报议题） Time 2020-10-28 9:30-11:30((UTC+08:00)Beijing) --- 会议信息 --- 会议id: 96457420049 会议链接：https://zoom.us/j/96457420049?pwd=di95MnJaUU1sNmxFQWMrNjBMZFBEZz09 --- 会议纪要归档 --- Meeting Record： https://gitee.com/openeuler/release-management/wikis

1 0

openEuler 选择 5.10 作为下一个长期维护的内核版本 (公示)
by Xie XiuQi 27 Oct '20

27 Oct '20

openEuler 选择 5.10 作为下一个长期维护的内核版本 (公示) - /本文//链接 <https://gitee.com/openeuler/community/blob/master/sig/Kernel/kernel-upgrade…>/ Linux 5.10 预计是 Linux 社区今年的 LTS (long-term support) 版本。openEuler 社区经过多轮沟通，选择 5.10 作为 openEuler 内核的下一个长期维护版本（openEuler Long-term support Kernel, OLK）。openEuler 社区提供不少于4年的维护时间和不少于2年的扩展维护时间。按照规划 openEuler 21.03、21.09 以及 openEuler 22.03 LTS 都将选择该内核版本。（具体时间以openEuler社区官网公布为准）升级安排： * v5.10-rc1 版本发布后，openEuler master 分支切换成 5.10。 * 由于主线 rc 版本尚在更新，openeuler_defconfig 暂时在 src-openeuler/kernel 仓库中提供，待 5.10 正式版本发布之后，再提交到源码仓库。 * openeuler_defconfig 基于 openEuler 20.09 的 config 修改适配，后续根据需求进行调整。 * 版本号格式，切换成 5.10.0-<devel_release>.<maintainence_release>。 * 首先支持 arm64 和 x86_64 架构，risc-v 的支持需要 risc-v sig 做适配。 * 上游社区 5.10 正式发布后（预计12月下旬）， openeuler/kernel 正式建立 OLK-5.10 分支（OLK: openEuler Long-term support Kernel），作为 5.10 的长期维护分支，接受补丁。 * 上游 5.10 正式发布前，如果有补丁需要发送 5.10，可以在 kernel(a)openeuler.org <mailto:kernel@openeuler.org> 中发 RFC 补丁，提前 Review 和讨论。 * 我们也可能提前建立 OLK-5.10 分支，以提前合入部分补丁做验证，但是在上游社区 5.10 正式发布之前，该分支可能会经常做 rebase 和 force push。对 OLK-5.10 或 openEuler 21.03 kernel 的需求 * 需求可以在 https://gitee.com/openeuler/kernel/issues 中提出。 * 如对 defconfig 有诉求也请在上述链接中提 issue。 * openEuler 21.03 计划使用该内核版本，预计2021年1月份之后，将从 OLK-5.10 拉出 openEuler-21.03 维护分支，同时补丁将受限合入 openEuler 21.03。注意事项和说明 * OLK 是 openEuler Long-term support Kernel 的缩写。openEuler LTS 版本和部分创新版本的内核基于 OLK 拉出分支进行维护。 * openEuler 5.10 内核不是基于 openEuler 4.19 内核的演进，而是基于上游社区内核的重新选型，因此如果您之前有合入 openEuler 4.19 的补丁，且这些补丁没有进入上游 5.10 内核，则需要您重新适配后推送到 openEuler 5.10 内核。 * openEuler 5.10 和 openEuler 4.19 两个版本 kabi 不兼容，您在 4.19 编译的 ko 不能直接在 5.10 上安装使用，需要重新适配和编译。 * openEuler 4.19 内核仍然处于维护周期内，如果您正在使用 4.19 内核，也不必紧张，您仍然能收到 4.19 的更新和增强。问题反馈 * kernel 升级期间，如果遇到兼容性、功能等问题，可以在 https://gitee.com/openeuler/kernel/issues 提交 issue。有疑问也可以在 PR 评论中，或者提交 issue 讨论。 * 你也可以发邮件到 kernel(a)openeuler.org <mailto:kernel@openeuler.org> 报议题在 kernel sig 例会中讨论。 * 如果 kernel sig 范围内协调或解决不了的问题，你也可以在 tc 报议题讨论。相关讨论纪要 kernel-sig 切换 5.10 的会议纪要： https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/6… openEuler kernel 版本号在 TC 的议题及会议纪要： * 议题及讨论记录： https://mailweb.openeuler.org/hyperkitty/list/tc@openeuler.org/thread/KOHJN… https://mailweb.openeuler.org/hyperkitty/list/tc@openeuler.org/thread/VNJQ6… * 纪要： https://mailweb.openeuler.org/hyperkitty/list/tc@openeuler.org/thread/ZLAWQ…

1 0

会议纪要：回复：【Meeting Notice】sig-ai-bigdata regular meeting Time: 2020-10-22 19:30-20:30
by Hubble_Zhu 26 Oct '20

26 Oct '20

与会人：sinever，Hubble_zhu, hao, Hexiujun, ZhiBo Li, haowenchao, huzunhao, liuzhikang, wangli 会议纪要：进展： Hubble_Zhu: 1. Spark门禁x86构建通过，arm构建未通过。和GateKeeper sig交流是构建机器网络的原因。建议改为使用国内maven源 2. flink, hadoop, hive, hbase本地验证构建ok，待提交PR将包合入到openEuler上 Hao： 1. 尝试基于openEuler构建Zepplin，遇到了一些nodejs的依赖问题下一步计划： 1. 建议对大数据软件包maven依赖改为使用国内maven源，构建ok后提到openEuler上 ——Hubble Zhu 2. 建议将jupyter引入到openEuler上 ——Hubble Zhu 3. 建议解决nodejs相关的依赖问题，继续尝试将zepplin引入到openEuler上 ——hao 新项目启动：提供面向个人爱好者、科研人员、企业等提供全场景，高性能，易用的 ai/bigdata 的统一平台一键安装、部署、运行支持单机、集群、各种云屏蔽采集、存储、分析、训练等300+开源软件屏蔽虚拟机/物理机/数据中心/各种云屏蔽计算、网络、存储等基础设施大家有任何关于新项目的想法，欢迎加群一起讨论： PS: 非常感谢 ZhiBo Li 对bazel，TensorFlow构建做出的尝试和贡献非常感谢 Hao 对openEuler引入Zepplin做出的贡献 ------------------ 原始邮件 ------------------ 发件人: "Meeting Book" <uMeeting(a)huawei.com>; 发送时间: 2020年10月22日(星期四) 上午9:03 收件人: "Hubble_Zhu"<hubble_zhu(a)qq.com>; 主题: 【Meeting Notice】sig-ai-bigdata regular meeting Time: 2020-10-22 19:30-20:30 Topic sig-ai-bigdata regular meeting Time 2020-10-22 19:30-20:30((UTC+08:00)Beijing)   Join Conference Join (External) >> Meeting ID 595 278 462   Convener 朱恒博   Agenda 1、sig成员前期工作审视 2、下一步计划与分工   Tips: Dial the access number to join conference 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载 If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download

2 1

【Meeting Notice】sig-ai-bigdata regular meeting Time: 2020-10-22 19:30-20:30
by Hubble_Zhu 22 Oct '20

22 Oct '20

Topic sig-ai-bigdata regular meeting Time 2020-10-22 19:30-20:30((UTC+08:00)Beijing)   Join Conference Join (External) >> Meeting ID 595 278 462   Convener Hubble_Zhu   Agenda 1、sig成员前期工作审视 2、下一步计划与分工   Tips: Dial the access number to join conference 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载 If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download

1 0

【会议纪要】 RE: 【Meeting Notice】【议题收集】openEuler TC例会 Time: 2020-10-21 10:00-12:00
by Zhanghailiang 21 Oct '20

21 Oct '20

议题1. 升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致 --- xiasenlin 会议纪要： 1) TC无法根据当前提供信息决定gcc是否升级，gcc组件升级由编译器sig分析决定 2) 针对firefox 79.0的CVE漏洞，需要升级到更高版本firefox修复的问题，优先采用openeuler发布版本中gcc 7.3版本编译高版本firefox修复，另外可以选择同时保留gcc 7.3版本和gcc 9.3版本，但是要确保两个gcc版本共存不相互影响 3）长远规划需要考虑openeuler上支持的浏览器情况，如果firefox存在大量漏洞，需要考虑用其他浏览器替换议题2. openEuler kernel 5.10 内核版本号改进方案 -- 谢秀奇会议纪要： 1) 整体上同意版本号改进方案。可以社区发文解释一下，特别是《stable版本号》是否更新，多征求下意见。也可以在summit中做一次讨论。议题3. UKUI SIG、HA SIG 和 ovirt SIG工作进展，以及未来的工作规划汇报（麒麟）会议纪要： 1) 请UKUI, HA, oVirt SIG组和release management SIG沟通，明确版本节奏。 2) 请release SIG组依照反馈的意见，改进release的发布模式，沟通模式，诸如版本时间roadmap, 组件升级情况，版本各阶段时间点等信息汇总到openeuler各sig组员可见的地方，同时要主动和各个SIG组进行协调，不能只依赖SIG组的主动上报议题4. GCC社区版本规划 --郭歌，张海建会议纪要： 1）同意gcc升级策略，会后需要将gcc升级规则文字和图片描述清楚，发布在openEuler博客中，并且在Compiler SIG首页注明gcc roadmap 议题5.关于openEuler 集成的衰退软件的处理建议 --李次华会议纪要： 1）软件退出细则大家基于PR 讨论： https://gitee.com/openeuler/community/pulls/1171 2）在软件引入与退出是宽进严出原则，软件包转移到recycle-sig 后，会继续向外发布，并且告知下游使用风险，执行删除时采取TC 委员投票方式决策 3）部分关键软件上游停止维护的自建仓维护是合理的，为了方便其他国家参与，在github 建仓，在gitee上建立mirror From: Zhanghailiang [mailto:zhang.zhanghailiang@huawei.com] Sent: Wednesday, October 21, 2020 8:54 AM To: tc(a)openeuler.org Cc: douyan(a)kylinos.cn; 侯健 <hj19870806(a)163.com>; yangzhao1(a)kylinos.cn; jiangxinyu(a)kylinos.cn; Xiexiuqi <xiexiuqi(a)huawei.com>; xiasenlin <xiasenlin1(a)huawei.com> Subject: [Tc] 【今日议题】 RE: 【Meeting Notice】【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time: 2020-10-21 10:00-12:00 1）升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致 --- xiasenlin 2）议题申报：openEuler kernel 5.10 内核版本号改进方案 -- 谢秀奇 3）UKUI SIG、HA SIG 和 ovirt SIG工作进展，以及未来的工作规划汇报（麒麟） From: Meeting Book [mailto:uMeeting@huawei.com] Sent: Monday, October 19, 2020 8:59 AM To: tc(a)openeuler.org<mailto:tc@openeuler.org> Subject: [Tc] 【Meeting Notice】【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time: 2020-10-21 10:00-12:00 Topic 【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time 2020-10-21 10:00-12:00((UTC+08:00)Beijing) Join Conference Join (External) >><https://welink-meeting.zoom.us/j/448457115> Meeting ID 448 457 115 Convener 张海亮 Tips: Dial the access number to join conference<http://app.huawei.com/eshare/voiceMeetings> 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载<https://zoom.us/download> If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download<https://zoom.us/download>

1 0

【Meeting Notice】sig-ai-bigdata regular meeting Time: 2020-10-22 18:30-19:30
by Hubble_Zhu 21 Oct '20

21 Oct '20

Topic sig-ai-bigdata regular meeting Time 2020-10-22 18:30-19:30((UTC+08:00)Beijing)   Join Conference Join (External) >> Meeting ID 595 278 462   Convener Hubble_Zhu   Agenda 1、sig成员前期工作审视 2、下一步计划与分工   Tips: Dial the access number to join conference 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载 If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download

1 0

Re: TC 议题申报：openEuler kernel 5.10 内核版本号规则改进方案
by Xie XiuQi 21 Oct '20

21 Oct '20

Hi，我发现我们理解有不一致的地方，我在下面画个图澄清一下。看一下我有没有解释清楚。另外，看到你邮件里面有一个保密声明，因为是社区公开讨论，没有保密信息。你后面把这个声明去掉吧，避免引起不必要的麻烦。 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. On 2020/10/20 16:51, Erik Yuan wrote: > Hi, > > > 基于之前的讨论，我搞了下面的图。希望没有将问题复杂化:( 没有复杂化，你发了这个图，讨论更清晰了。我发现我们理解有不一致的地方，我画个图澄清一下。看一下我有没有解释清楚。你看一下这个图能解释你的疑问吗? > > > 目前openEuler kernel的分支与上游社区的 kerenl分支的大概层次关系是： > > 5.10.9 5.10.10 5.10.30 5.10.40 5.10.50 > 上游某个LTS 5.10.Z -----*-------*--------------*----------------------- *-----------------------------*-------------------------------------------------> > Pull | | | | > V V V V > openEuler xx.03 LTS(所谓开发主分支) *----p---p----*----p------p----------*----p---*-------------------*------p------------*----p----------------------> > 5.10.10-1.0.05.10.10-2.0.0 | 5.10.10-4.0.05.10.10-6.0.0 | > | | > V V > xx.03 LTS SPn(派生分支) *-----p-------p-----*---------p-------------------*-------------------------------------> > 5.10.10-3.0.0 5.10.10-5.0.05.10.10-7.0.0 > > > > 5.10.10 > openEuler xx.09 inno(独立开发主分支) *------------------------*-----------------------*---------------------------------------> > 5.10.10-?.0.05.10.30-?.0.05.10.40-?.0.0 > > > 这里考虑引入 <stable版本号> -<开发版本号>.<维护版本号>.<构建号/buildid> 的目的之一是 ‘体现主干与分支的关系’。 > 但有几个问题： > 1）目前 LTS SP?拉出分支后，原来 LTS第一个版本（标记为SP0）是否还出kernel RPM？我理解的还是要出的。那么是否出现上图的版本编号？要出 RPM，参考上图，SP0 也是一样，分支拉出来，后续就只更新 Maintenance 号，不存在号码段的问题。 > 这样单纯从kernel版本号似乎也不好直接区分出来是来自开发主分支还是 SPn分支的。除非<开发版本号>采用 3k + n(n=1对应SP1)的方式。 > 2）假如某个innovation版本选择的<stable版本号> 与某个 LTS版本选择的一样（上游同源)，基于<开发版本号> 是从属于5.10.Z 的，那岂不是也得于该 LTS版本的<开发版本号> 进行统一编号？ > 但这个编号同样的不好直接区分该版本是来源于哪个分支。 > 编译生成RPM后，会归到不同的 openEuler release 库中，即便RPM包的版本号都是 5.10.10-?.0.0 在多个openEuler 的package repo中出现，还是能从目录path能区分出来。但是在 OBS中看到的tarball包的版本号都是 5.10.10-?.0.0， > 这个是否容易犯错？如果能做到从版本号能直观的区分是来自哪个branch，对后续可能的程序检查等处理的引入会方便的多。版本号如果相同，就能确定是使用相同的源码，即 git 库中相同的 tag。 > > 因此，我建议， > 1) <开发版本号> 是基于某个开发主分支来进行全局编号，而不是基于 <stable版本号>; 开发主分支之间的区分通过dist release来区分？是全局的。 > 2) 同一开发主分支所派生的下游分支，<开发版本号> 不是按主分支出版本的时间先后来定义，可以考虑将<开发版本号> 以一定的步长来划分不同的编号区间，譬如 0~ 9999, 10000 ~ 19999, ..... 每个步长 10000. > 目前我们是有3个SP, 谁知道以后有多少个SP？ > 3) <stable版本号>中的 X.Y.Z 的Z，其实在当前的新版本号方案中，没有什么作用，不直接用于区分源分支。保持与 kernel社区一致应该可以接受，能直观反映于上游的关系。 > > > Cheers, > Erik > > > -----Original Message----- > From: Xie XiuQi <xiexiuqi(a)huawei.com> > Sent: Tuesday, October 20, 2020 3:06 PM > To: Erik Yuan <Erik.Yuan(a)arm.com> > Cc: tc <tc(a)openeuler.org> > Subject: Re: [Tc] TC 议题申报：openEuler kernel 5.10 内核版本号规则改进方案 > > Hi, > > 尝试按我的理解解释了一下；-） > > On 2020/10/20 13:39, Erik Yuan wrote: >> Hi Xiuqi, >> >> 多谢详尽的解释, 澄清了好些过往的一些错误理解：） >> 还有点疑问。 >> >> >> On 10/19/2020 3:22 PM, Xie XiuQi wrote: >>> Hi, >>> >>> 非常感谢参与openEuler kernel 的讨论： >>> >>> On 2020/10/19 13:37, Erik Yuan wrote: >>>>> 且，如果主干和分支如果在同一个月都发版本时，有可能引起版本号重复。如都是10月份 >>>>> 第2个版本，则版本号后缀都是 -2010.2.0 >>>>> - <年月>.<月份内Release号> ，不能体现大版本小版本的层级关系 >>>>> >>>>> 2 改进方案（以 5.10 内核为例） >>>>> >>>>> 版本号格式：(格式与原方案完全相同，只是各字段含义有细微变化） >>>>> >>>>> 5.10.0-<开发版本号>.<维护版本号>.<构建号/buildid> >>>>> >>>>> 总体思路： >>>>> - 上游版本号选定后，上游版本号保持不变；只更新下层版本号； >>>> 诸如 5.10.0 的上游版本号是否还是保持与上游一致？反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。 >>> 4.19 上，关于 sublevel 版本号，下游有多次混淆和误解这个含义。而且，就在我准备 >>> 回这封邮件的时候，又有人找我澄清这个事情。 >>> >>> 比如，以 openEuler 20.03 LTS 为例，对应的内核源码版本号是 4.19.90-2003.4.0， >>> 有多个下游团队误以为这个版本是基于 Linux stable 4.19.90 开发的，在进行上游 >>> 社区溯源时就会出错，出现不必要的麻烦。而实际上，针对 Linux stable 的补丁， >>> openEuler kernel 是进行 backport 操作，所以在 git log 中，不能说是基于 4.19.90 >>> 开发的，4.19.90-2003.4.0 的上游版本并不是 Linux stable 4.19.90。 >>> （通过 git log 可以发现，openEuler 4.19 kernel 的上游版本是 linux stable 的 4.19.13） >>> >>> c04c050f5bf9 (tag: v4.19.13) Linux 4.19.13 >>> >> 也就是目前从stable同步 4.19.x 后修改openEuler kernel的sublevel 是与 stable 的x不一致的？目前是 openEuler 的sublevel > 主线的sublevel。 >> 之前理解openEuler kernel的sublevel 是对应stable kernel的sublevel。 > 是一致的。openEuler kernel 回合 4.19.x 的补丁之后，sublevel 就变为 x. > 在 4.19 上，实际上是把 stable 中修改 Makefile sublevel 的补丁也backport回来了。 > > commit 94a531f89cf3c6c40bebee7acab581a8033a5283 (HEAD -> kernel-4.19, origin/kernel-4.19) > Author: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Date: Mon Oct 19 21:23:04 2020 +0800 > > Linux 4.19.152 > > Merge 19 patches from 4.19.152 stable > branch (22 total) beside 3 already merged patches: > 128278f444ab Bluetooth: A2MP: Fix not initializing all members > 360f80e34292 Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel > 7b2e80606a5d Bluetooth: MGMT: Fix not checking if BT_HS is enabled > > Tested-by: Pavel Machek (CIP) <pavel(a)denx.de> > Tested-by: Jon Hunter <jonathanh(a)nvidia.com> > Tested-by: Guenter Roeck <linux(a)roeck-us.net> > Tested-by: Linux Kernel Functional Testing <lkft(a)linaro.org> > Link: https://lore.kernel.org/r/20201016090437.301376476@linuxfoundation.org > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> > > diff --git a/Makefile b/Makefile > index f2c9db9b4015..aa79ce7bfdc7 100644 > --- a/Makefile > +++ b/Makefile > @@ -1,7 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0 > VERSION = 4 > PATCHLEVEL = 19 > -SUBLEVEL = 151 > +SUBLEVEL = 152 > EXTRAVERSION = > NAME = "People's Front" > >> 那么如果基于新方案，引入 <开发版本>.<维护版本>后，是否可以将sublevel 在某个tag后调整回去与 stable保持一致？然后sublevel 只在每次与stable kernel同步后 >> 才更新演进。期间发生的kernel build版本只是变更 <开发版本>?? 这样从openEuler kernel的版本号能比较直观的建立与stable kernel的关系。 >> > 我原本也是你说的这个思路，而且 4.19 也是这么做的，完整的合入社区 stable 的版本 4.19.x 之后，sublevel 也改为 x。 > 是由于前面我提到的一些误解，所以现在想保持 sublevel 不变。 > 不过，我个人是可以接受 seblevel 与回合的社区 4.19.x 的相同的。 > 虽然从严格意义上讲，由于已经合入了其他的补丁，openEuler kernel sublevel 的含义与 stable 的有细微的差别， > 但确实是能与 stable kernel 建立直观的联系。 > > 有利有弊，对熟悉 kernel 开发的人来说，与 stable kernel 的sublevel建立联系，能帮助我们了解跟踪到了哪个 stable 版本。 > 对于不熟悉 kernel 开发的人来说，他看到就是一个版本号，他们以为 sublevel 变了，就后面的一切都变了。或者以为你这个 > 版本的 base 就是 VERSION.PATCHLEVEL.SUBLEVEL。 > >>> 上面提到的“反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。”， >>> 我确实是这个想法：选择了上游社区的某个版本，之后就是在 openEuler 社区的开发、回合， >>> 保持上游版本号固定，之后就只更新openEuler社区的版本号部分。 >>> >>>> 版本号是否可以借鉴一下 suse的，例如 >>>> 5.3.18-18.21--sle15-sp2 >>>> >>>> 5.3.18-lp152.19.2 >>>> >>>> 之类，通过添加一个dist ver之类的string字段来区分。是否能解决问题？ >>>> 个人觉得openEuler LTS的kernel 还是会不时同步对应的 upstream kernel的，也就是 5.10.x而不是 sublevel 总是0。 >>> openEuler LTS 的 kernel 会定期同步 upstream kernel 的，也就是 5.10 也会定期同步 linux stable 5.10.x 的补丁。 >>> 确实是这样的，而且 openEuler 的 4.19 内核，再 backport 对应的 stable 版本之后，也会修改 sublevel。 >>> 实际执行过程中，遇到上面的问题。也是我提议改成 sublevel version 保持不变的重要原因。当然，在 backport 时， >>> git log 中会描述补丁来自哪个 stable 版本，在 release note 中也会说明，同步到哪个 stable 版本了。 >>> >>> 另外，suse 保留了 sublevel 更新的一个原因，应该与其补丁管理方式有关，suse 使用 quilt 管理补丁，相当于 >>> 上游 stable 版本有更新时，做了 rebase 操作，更新 sublevel 顺理成章。 >>> >>> 关于你上面提到的 dist ver 之类的 string 字段，我的想法是，5.10 的版本号规则，在 4.19 上微调，尽量 >>> 避免在格式上有大的变动，毕竟 4.19 已经有很多下游在使用了;-） >> 目前 openEuler的kernel版本号能区分innovation 和 LTS 么？ > openEuler kernel source 的版本号，没有区分 innovation 和 LTS。 > 我理解应该是看 openEuler 版本的发布时机，来选择采用哪个版本的 > openEuler kernel。 > > 按照现在的 LTS 策略，肯定会出现 innovation 和 LTS 都采用 5.10 内核的情况， > 但是由于 innovation 和 LTS 发布时机不同，选用内核时，<开发版本> 是不同的。 > > 更极端的情况，innovation 和 LTS 假设选择的内核，<开发版本> 也相同，那也好办， > innovation 和 LTS 这时就干脆使用相同版本的内核，包括 Maintenance 号。可能只是 > 打包时，rpm 包的后缀有区别，oe1 这个字段。 > > >> 按照目前 LTS 和 innovation 选择 upgrade kernel的策略（都选择Linux LTS)，可以出现 openEuler 某个LTS 版本选择的 Linux kernel LTS版本与innovation版本选择的 Linux kernel LTS版本一致的情况。 >> 此时如何区分两个版本所发布的kernel包？ <开发版本> 我理解应该是从属于 VERSION.PATCHLEVEL.SUBLEVEL 下的，而不是整个openEuler 全局编号的。 > <开发版本> 是 openEuler kernel 全局的，是在 4.19、5.10 等，每个大版本范围内是全局的， > 不是从属 VERSION.PATCHLEVEL.SUBLEVEL，而是可以理解为从属 VERSION.PATCHLEVEL。 > 不管 SUBLEVEL 更新还是保持不变，都不应该影响 <开发版本> 的更新。 > > 如果 <开发版本> 从属于 VERSION.PATCHLEVEL.SUBLEVEL 的话，会有问题，就会出现 > 下面这样的版本号序列，体现不出openEuler kernel 的演进关系，<开发版本> 会经常 > reset. > > 三个思路对比： > <从属 sublevel> <sublevel更新,开发版本全局> <sublevel 不更新> > 5.10.1-1.0.0 5.10.1-1.0.0 5.10.0-1.0.0 > 5.10.1-2.0.0 5.10.1-2.0.0 5.10.0-2.0.0 > 5.10.1-3.0.0 5.10.1-3.0.0 5.10.0-3.0.0 > 5.10.1-4.0.0 5.10.1-4.0.0 5.10.0-4.0.0 > 5.10.2-1.0.0 5.10.2-4.0.0 5.10.0-5.0.0 > 5.10.3-1.0.0 5.10.3-4.0.0 5.10.0-6.0.0 > 5.10.3-2.0.0 5.10.3-5.0.0 5.10.0-7.0.0 > > 综上，应该是上面 2 3 两个方案里面选择一个，我之前说的是方案3，如果更新 sublevel 的话， > 就是方案2。我个人倾向于3，但我能接受2. > >> >> 谢谢！ >> Erik >> >> >>> 上面是我的观点和理由，再次感谢参与讨论，本周tc上，也看一下大家的意见。 >>> >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. >> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

2 2

【今日议题】 RE: 【Meeting Notice】【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time: 2020-10-21 10:00-12:00
by Zhanghailiang 21 Oct '20

21 Oct '20

1）升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致 --- xiasenlin 2）议题申报：openEuler kernel 5.10 内核版本号改进方案 -- 谢秀奇 3）UKUI SIG、HA SIG 和 ovirt SIG工作进展，以及未来的工作规划汇报（麒麟） From: Meeting Book [mailto:uMeeting@huawei.com] Sent: Monday, October 19, 2020 8:59 AM To: tc(a)openeuler.org Subject: [Tc] 【Meeting Notice】【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time: 2020-10-21 10:00-12:00 Topic 【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time 2020-10-21 10:00-12:00((UTC+08:00)Beijing) Join Conference Join (External) >><https://welink-meeting.zoom.us/j/448457115> Meeting ID 448 457 115 Convener 张海亮 Tips: Dial the access number to join conference<http://app.huawei.com/eshare/voiceMeetings> 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载<https://zoom.us/download> If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download<https://zoom.us/download>

1 0

TC 议题申报：openEuler 社区关于上游停止维护或衰退软件处理建议
by Licihua 21 Oct '20

21 Oct '20

背景：经抽查openEuler LTS 范围内的900+ 软件，发现其中200+ 软件2年内未发布新版本，80+ 软件上游社区半年内未处理Issue 与PR，18款软件为2010 年前发布，30款软件为2015 年前发布；为了保证openEuler 集成软件质量，针对上游宣布停止维护或实际停止维护软件需要考虑如何保证质量，保证客户持续的高质量体验。处理建议： 1、软件引入时增加社区状态检查： 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入， 2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入， 3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。 2、增加软件退出规则：当满足以下两个条件时，openEuler软件包的退出申请可以被立即执行，对应repo将从项目中直接删除。 1、软件的License 或出口管制策略影响了目前正在使用的版本，导致openEuler存在商务或者法务上的风险，不能继续集成该软件 2、存在恶意代码或严重安全隐患且openEuler 社区无能力修复的，要求软件被立即移除。除以上描述两种场景外，剩下的场景openEuler对软件包的退出实行过程化管理： 1、随着技术演进与发展，软件因技术陈旧或架构落后，不能满足现有的应用场景被其他更优秀的软件所取代。 2、软件新版本License 或出口管制策略变化导致openEuler 不能集成，openEuler 已经集成的旧版本过于老旧。 3、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的。 4、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，社区半年以上未响应的。 5、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，社区半年以上未响应或者答复停止维护的。如果软件满足退出条件，但是因openEuler 社区其他软件存在依赖且短时间不能解除或者下游切换周期过长而不能立即退出的，可以由依赖方所在SIG 或原SIG在github 上建立仓库自行维护。 3、增加自维护策略：开源软件符合退出条件，但是因上下游切换周期长，短时间不能退出的，由依赖方SIG或者本SIG 自建仓维护，具体原则如下： 1、知名社区或组织宣布停止维护、License 变化或出口管制原因导致不能集成新版本的，短期内由软件所在 SIG 建立的github 项目维护，并且寻找替代软件，推动上下游尽快切换。 2、个人、小型社区或组织投入不足的，优先联系社区maintainer，传递openEuler 参与贡献的意愿，重新激活上游社区。maintainer 不响应的，需要将软件迁移到openEuler SIG 在github 建立的项目下，由openEuler SIG维护。迁移后需要在原始上游社区发布openEuler SIG继续维护软件的通知，吸引社区其他参与者成为贡献者。 4、增加自维护质量要求： 1、运行在数据面^1的关键软件（例如glibc、dpdk），或者运行在控制面^2/管理面^3，但是可能导致下游客户出现现网事故的（例如升级相关软件dnf）或暴露攻击面的软件（例如网络服务 vsftpd）， 2、需要梳理特性应用场景、规格、使用约束与限制；梳理代码关键流程、开展代码检视工作；补充特性测试、组织各类专项测试、安全/韧性测试、开展薄弱特性质量改进工作。 3、运行在控制面^2/管理面^3，但是常驻系统或高频执行的软件（systemd、sshd)，需要梳理特性应用场景、规格、使用约束和限制，结合特性使用场景开展代码检视；结合特性使用场景补充测试、开展各类专项测试、薄弱质量改进工作。 4、运行在管理面^3且使用频率低，应用场景稳定的（例如anaconda，dconf），通过问题触发方式熟悉代码流程，开展专项测试。 5、不在客户现网环境运行或不影响客户现网运行的软件（如CUnit、Make、gdb），在openEuler 制品仓中维护，基于开源测试代码展开测试活动，定期从友商社区（例如fedora、openSuse）同步补丁代码。原文PR 如下：https://gitee.com/openeuler/community/pulls/1171/files 欢迎各位发表意见李次华欧拉部-2012 实验室华为技术有限公司 Tel : +86 15158056404 Email : licihua(a)huawei.com [cid:image003.png@01D6A6CC.5CE72640] This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

4 3

TC 议题申报：openEuler kernel 5.10 内核版本号规则改进方案
by Xie XiuQi 20 Oct '20

20 Oct '20

海亮 & TC，议题申报：openEuler kernel 5.10 内核版本号改进方案（总体方案和 RHEL/CentOS kernel 版本号规则类似） 1. openEuler kernel 版本号，原方案及存在的问题（以 4.19 为例）版本号格式： 4.19.<stable 版本号>-<年月>.<月份内Release号>.<buildid> 说明： - <stable 版本号>，linux stable 分支版本，合入对应的stable 版本时更新如 4.19.90， 4.19.128 等等 - <年月>，标识版本发布时的年份&月份，如 2010 表示2020年10月份，2009 表示20年9月份 - <月份内Release号>，标识本月内发布的第几个版本，比如 2020年10月份发的第2个版本，则版本号为 xxxx-2020.2.0 - buildid, 构建号，不管是代码还是制品仓，只要有修改要出rpm包，就在之前基础上 +1 存在的问题： - 上述方案，如果只有一条分支，则问题不大，版本号顺序增加 - 如果有多个分支，则可能存在分之间版本号混淆，不能体现主干与分支的关系等问题 - 比如，主干在开发时，<stable 版本号>.<年月>.<月份内Release号> 这几个版本号都在变化；openEuler发布后，<年月>.<月份内Release号> 这几个版本号也都在更新，且，如果主干和分支如果在同一个月都发版本时，有可能引起版本号重复。如都是10月份第2个版本，则版本号后缀都是 -2010.2.0 - <年月>.<月份内Release号> ，不能体现大版本小版本的层级关系 2 改进方案（以 5.10 内核为例）版本号格式：(格式与原方案完全相同，只是各字段含义有细微变化） 5.10.0-<开发版本号>.<维护版本号>.<构建号/buildid> 总体思路： - 上游版本号选定后，上游版本号保持不变；只更新下层版本号； - 社区 5.10.0 是开发分支的上游，选定后，保持不变；开发分支有更新，只升级<开发版本号> - 开发分支是维护分支的上游，一旦选定某个开发版本，转维护时，只升级<维护版本号> - 通过<开发版本号>和<维护版本号>，体现开发与维护的关系 - 主干开发与多个维护分支共同存在时，版本号不混淆，能清晰体现上下游关系各字段具体说明： 1） 5.10.0 前面的基础版本号不变，一直是 5.10.0，不体现 stable 的小版本号； 2）后面几位是 <开发版本号>-<维护版本号>-<构建号/buildid> 比如：5.10.0-2.0.0.0007.oe1.aarch64 %global upstream_version 5.10 %global upstream_sublevel 0 %global devel_release 2 %global maintenance_release .0.0 %global buildid .0007 3）版本号思路： - 开发的时候，只更新<开发版本号>，<维护版本号>保持为 .0.0 - openEuler 发行版发布之后，只更新<维护版本号>，<开发版本号>固定不变 - <构建号/buildid>，构建号，不管是代码还是制品仓，只要有修改要出rpm包，就在之前基础上 +1 4）例子： - 开发的时候，只更新<开发版本号>，维护版本号保持为 .0.0 源码 tag: 5.10.0-1.0.0，制品仓 release: 5.10.0-1.0.0.0001.oe1.aarch64 源码 tag: 5.10.0-2.0.0，制品仓 release: 5.10.0-2.0.0.0002.oe1.aarch64 源码 tag: 5.10.0-3.0.0，制品仓 release: 5.10.0-3.0.0.0003.oe1.aarch64 - openEuler 发行版发布之后，假设从 5.10.0-123.0.0 开发版本转 openEuler 发布，之后再合入维护补丁，就只更新维护版本号（最后那个 0 预留，紧急情况下使用）源码 tag: 5.10.0-123.1.0 制品仓 release: 5.10.0-123.1.0.0041.oe1.aarch64 源码 tag: 5.10.0-123.2.0 制品仓 release: 5.10.0-123.2.0.0042.oe1.aarch64 源码 tag: 5.10.0-123.3.0 制品仓 release: 5.10.0-123.3.0.0043.oe1.aarch64 。。。 - 假设后续有 SP 版本从 5.10.0-456.0.0 开发版本发布，之后再合入维护补丁，就只更新<维护版本号> 源码 tag: 5.10.0-456.1.0 源码 tag: 5.10.0-456.2.0 源码 tag: 5.10.0-456.3.0 。。。 - 开发分支上回合 stable 补丁时，也是只更新<开发版本号> 5）相比之前的好处：相比之前通过月份来定版本号的好处，通过区分开发版本号，和维护版本号，体现主干和和维护分支的关系。之前月份命名版本号，在分支多的情况下，存在混淆的情况，比如，相同月份不同分支的 release 号可能会重复，比如都是10月份的第一个版本：-2010.1.0 3. 影响

4 9

【议题收集】【Meeting Notice】openEuler kernel sig meeting Time: 2020-10-16 10:00-12:00
by Xie XiuQi 20 Oct '20

20 Oct '20

openEuler kernel sig meeting 定于 2020-10-16 10:00-12:00 召开，欢迎回复邮件申报议题。 --- 会议信息 --- 会议链接：https://zoom.us/j/94156903933 会议 ID : 94156903933 --- 会议纪要归档 --- Meeting Record 20200918： https://gitee.com/openeuler/kernel/issues/I1WGN0

1 3

TC议题申报：openEuler社区gcc编译器版本计划
by guoge (A) 19 Oct '20

19 Oct '20

Hi, tc team 申请议题讨论：openEuler社区gcc编译器版本计划该讨论将决定未来每个openEuler版本中支持的gcc编译器版本，由于gcc属于基础设置，版本变动影响面较大，所以gcc版本选型的原则首先是稳定，其次才是新功能目前初步方案如下： 1． gcc一年升级一个大版本，在每年下半年的openEuler创新版本中引入，并维护一年到下一年度上半年的openEuler版本，例如在openEuler 20.09版本中引入gcc 9，并持续维护到openEuler 21.03版本 2．每次升级会选取最新gcc大版本的.3版本作为稳定版本，例如认为gcc 10.1和gcc 10.2不是稳定版本，gcc 10.3是稳定版本，由于2020.9最新的gcc大版本是gcc 9和gcc 10，且gcc 9有9.3版本，gcc 10只有10.2版本，所以选择9.3作为稳定版本 3．每一个gcc大版本只会选择.3作为稳定版本，不升级，有问题或需求采用backport模式，例如openEuler 20.09和21.03都采用gcc 9.3，不会升级到gcc 9.4 具体计划如下： [cid:image001.png@01D6A61E.88FE5F90] 材料见附件

2 1

会议纪要 //回复：【Meeting Notice】sig-high-performance-network regular meeting Time: 2020-10-15 19:00-20:00
by Peanut_Huang 19 Oct '20

19 Oct '20

与会人：Mr.lu, hubble_zhu, peanut_huang, gao_xiingwang, yuan_xin, xu_changye 【会议纪要】前期进展： 1. polycube框架已经成功在openEuler上运行，相关修改等待合入社区 -- liu_xin 2. 将polycube相关工具包推到openEuler上     swagger-codegen已在本地成功构建和运行，待提交合入社区 -- peanut_huang     pyang-swagger依赖pyang，正在验证pyang的构建 -- gao_xiingwang 下一步计划： 1. 建议尽快将polycube相关工具包推到openEuler上     pyang-swagger、pyang -- gao_xiingwang     polycube-codegen   -- peanut_huang     xdp-tools        -- hubble_zhu 2. 建议补充部分高性能网络sig的愿景材料 -- Mr.lu ------------------ 原始邮件 ------------------ 发件人: "Peanut_Huang" <hlm3280(a)qq.com>; 发送时间: 2020年10月14日(星期三) 晚上7:25 收件人: "high-performance-network"<high-performance-network(a)openeuler.org>;"tc"<tc(a)openeuler.org>;"dev"<dev(a)openeuler.org>; 主题: 【Meeting Notice】sig-high-performance-network regular meeting Time: 2020-10-15 19:00-20:00 Topic sig-high-performance-network regular meeting Time 2020-10-15 19:00-20:00((UTC+08:00)Beijing)   Join Conference Join (External) >> Meeting ID 985 033 429   Convener Peanut_Huang Agenda 1.sig成员前期工作审视 2.下一步工作和计划 Tips: Dial the access number to join conference 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载 If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download

1 0

【议题申报】为满足SP1版本新特性，申请升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致
by xiasenlin 19 Oct '20

19 Oct '20

Hi，Xiuqi 和各位 TC 委员，当前在升级 openEuler:20.03:LTS:Next工程的单包firefox以解决CVE问题时，发现依赖高版本的gcc（9.3）, 与责任人郭歌沟通后，申请增加一个议题：升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致，希望与 TC 委员们和社区成员讨论。附件为原因分析。谢谢。 ——夏森林

7 7

【Meeting Notice】【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time: 2020-10-21 10:00-12:00
by Meeting Book 19 Oct '20

19 Oct '20

1 0

【Meeting Notice】sig-high-performance-network regular meeting Time: 2020-10-15 19:00-20:00
by Peanut_Huang 14 Oct '20

14 Oct '20

Topic sig-high-performance-network regular meeting Time 2020-10-15 19:00-20:00((UTC+08:00)Beijing)   Join Conference Join (External) >> Meeting ID 985 033 429   Convener Peanut_Huang Agenda 1.sig成员前期工作审视 2.下一步工作和计划 Tips: Dial the access number to join conference 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载 If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download

1 0

openEuler社区QA测试团队双周会议纪要（2020/10/14）
by liyongqiang (H) 14 Oct '20

14 Oct '20

openEuler社区QA测试团队双周会议时间： 16:00-17:00 2020/10/14 参会者：kuhnchen18 lutianxiong speacher lemon-higgins Charlie_li 会议纪要人: Charlie_li 分类遗留问题及其他进展状态责任人社区QA团队治理与运营 src_openeuler组织下申请制品仓 10/14:openEuler相关的test-tools/integration-test两个仓已经建立完成；包发布方式需和包管理团队对齐 Running Charlie_li/kuhnchen18 测试代码合规检查(shell/python) 10/14:python和java码云已支持；shell也已经对接，当前是默认配置检查； Running Charlie_li/kuhnchen18/ lemon-higgins 集成类测试能力开源 10/14:单包加固/系统用户集成/新特性的月底前开源 8/12:包差异代码评审后还需进一步整改 7/29:容器基本功能开源完成；包差异整改80% 7/15:容器基本功能已完成整改，待开源；包差异对比工具整改进行60% 7/1:AT用例已完成检视，rpm包差异对比工具和容器基本功能用例整改中 Running Charlie_li/lemon-higgins 内核和编译器提供指导文档说明如何使用内核LTP及gcc相关开源测试套 8/12:计划本周搞定 7/29:内核LTP的完成编写，之前由于蓝云网络问题，未上传，待提交PR 7/15:编译器指导文档已开源；内核LTP的完成编写，待提交PR 7/1:蓝云已提供，LTP待提交文档，GCC本周完成 Running rigorous 社区QA测试流程及指导文档编写 10/14:虚拟哈相关文档已写完，待开放到码云 8/12: 虚拟化相关文档已完成50% 7/29：虚拟化相关指导文档已完成40% 7/15:已和OSV厂商完成交流；虚拟化相关指导文档已完成20% 7/1:进展80%，待完善后与OSV厂商交流 6/17:QA团队指导文档编写进展50% Running Charlie_li/ kuhnchen18 社区issue提单及处理规范 10/14:发布issue提单指导手册和issue处理规范 Running Charlie_li 版本测试暑期2020活动 10/14:学生课题已提交结项报告，本周进行验收 7/29:一个学生已完成测试方案设计,待和学生对齐； 7/15:暑期活动学生已开学，进展有些慢，线下和学生单点沟通； 7/1:暑期2020活动lrzsz、mysql加固已有学生报名，待深入沟通 Running Charlie_li 高优先级组件包质量加固 8/12:Euleros完成7个包的加固；openEuler完成8个包的加固 7/29:已完成6个包的加固，openEuler版本测试中会在执行时覆盖 Pause Lutianxiong/lemon-higgins 缺陷分析 9/23: 完成9月份的issue分析并在openEuler 20.09版本中补充相应测试用例 8/12:暂无进展 7/15:缺陷分析模板已完成初步评审，先运作，有其它建议再补充；每月例行开展一次，李永强统一整理外部问题作为输入提供给其它领域进行分析 Running Charlie_li 问题回归策略 10/14:状态为“已完成”经过验证已解决的改完“已验收” 8/12:7月份最新的问题单已完成回归确认 7/15:各领域owner优先处理330后状态是“已完成”的缺陷；输入是严志华整理的issue表格 Running Charlie_li/speacher/rigorous/lemon-higgins/ltx

1 0

增删repository提案
by 安传旭 13 Oct '20

13 Oct '20

Hi TC: 【增删repository提案】 ROS-SIG申请新建10个新仓库，用来存放移植完成打包成功的package,提案PR链接：https://gitee.com/openeuler/c…

1 0