- Tc - mailweb.openeuler.org

【今日议题】 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