- Tc - mailweb.openeuler.org

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